|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ASF JIRA | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Displaying 352 issues at 18/Mar/20 03:02. |
| Project | Key | Summary | Issue Type | Status | Priority | Resolution | Assignee | Reporter | Creator | Created | Last Viewed | Updated | Resolved | Affects Version/s | Fix Version/s | Component/s | Due Date | Votes | Watchers | Images | Original Estimate | Remaining Estimate | Time Spent | Work Ratio | Sub-Tasks | Linked Issues | Environment | Description | Security Level | Progress | Σ Progress | Σ Time Spent | Σ Remaining Estimate | Σ Original Estimate | Labels | Development | Reviewers | Ignite Flags | Date of First Response | Git Notification Mailing List | Github Integrations - Other | Github Integration | Last public comment date | Git Repository Name | Global Rank | Git Repository Type | Skill Level | Affects version (Component) | Backport to Version | Fix version (Component) | Skill Level | Blog Administrator? | Blogs - Admin for blog | Existing GitBox Approval | Blogs - Username | Protected Branch | Blogs - Email Address | GitHub Options | Docs Text | Git Repository Import Path | New-TLP-TLPName | Blogs - New Blog Write Access | Blogs - Existing Blog Name | Enable Automatic Patch Review | Attachment count | Blog - New Blog PMC | Blog - New Blog Administrators | Blog - Write access | Epic Link | Change Category | Bug Category | Bugzilla - List of usernames | Bugzilla - PMC Name | Test and Documentation Plan | Bugzilla - Email Notification Address | Discovered By | Blogs - Existing Blog Access Level | Complexity | Bugzilla - Project Name | Severity | Bugzilla Id | Level of effort | Initial Confluence Contributors | Target Version/s | Bug behavior facts | Space Name | Lucene Fields | Space Description | Github Integration - Triggers | Workaround | Bugzilla Id | INFRA - Subversion Repository Path | Space Key | Testcase included | Estimated Complexity | Regression | Sprint | Rank (Obsolete) | Project | Review Date | Evidence Of Use On World Wide Web | Evidence Of Registration | Epic/Theme | Flagged | External issue ID | Priority | Reproduced In | Machine Readable Info | Tags | Review Patch? | Since Version | Reviewer | External issue URL | Hadoop Flags | Issue & fix info | Evidence Of Open Source Adoption | Flags | Source Control Link | Rank | Authors | Severity | Tester |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Commons Collections | COLLECTIONS-71 | Missing LICENSE in source distribution (commons-collections-1.0-src.tar.gz) |
Bug | Closed | Blocker | Fixed | Unassigned | Michael Marrotte | Michael Marrotte | 05/Mar/02 02:11 | 18/Mar/20 03:01 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 1.0 | 0 | 0 | Operating System: Linux Platform: Other |
The build.xml in "commons-collections-1.0-src.tar.gz", references the "LICENSE" file that does not exist. This blocks a successful build of the API docs, i.e. "ant doc" as in "README.TXT". I "touched ../../LICENSE" for a quick fix. --MTM |
17 years, 51 weeks, 6 days ago | 18927 | No Perforce job exists for this issue. | 0 | 6855 | 164637 | 0|i0sji7: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-23 | BeanMap.putAll(beanmap) fails |
Bug | Closed | Minor | Fixed | Unassigned | Joe Shelby | Joe Shelby | 30/Jul/02 03:08 | 18/Mar/20 02:52 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 2.0 | 0 | 0 | Operating System: other Platform: Other |
I created two beanmaps, both around objects of the same class, to try to effectively clone the underlying objects (this was before I looked harder and realized that BeanMap.clone() would try to instantiate a new object on its own). I found that this fails with a java.lang.IllegalArgumentException: The bean of type: com.isx.isaf.IsafAgentDescription has no property called: class The reason: BeanMap's underlying introspector notices the read-only property of "class" (the class of the bean object), and has a get() entry for it that has no matching put. When AbstractMap.putAll iterates through the values, it tries to put() the class value and this causes the failure. The workarounds is to reimplement putAll() outside the map and catch exceptions for every failed put (this should be the only one unless the bean itself has other read-only properties). BeanMap.clone() correctly checks for read-only properties and doesn't try to set them, but is limited to beans that have zero-parameter constructors; its real problem is that it is still "protected" in BeanMap, not public. Possible fix is to override putAll() from AbstractMap and check if the property is read-only before calling put() and ignoring it if it is. Options involving fixing put() itself would cause more problems than solutions, IMHO. Another fix is to catch the "class" property and filter it out completely so it never shows up in the keySet or entrySet at all. |
17 years, 34 weeks, 3 days ago | 18975 | No Perforce job exists for this issue. | 0 | 11262 | 164685 | 0|i0sjsv: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-28 | SequencedHashMap.indexOf(Object key) throws annoying exceptions |
Bug | Closed | Major | Fixed | Unassigned | Johal | Johal | 18/Oct/02 16:10 | 18/Mar/20 02:50 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 2.0 | 0 | 0 | Operating System: All Platform: All |
Is it intentional that SequencedHashMap.indexOf(Object key) throws a NullPointerException when the key does not exist in the map? Shouldn't it return -1 in those situations? Here is an addition to the TestSequencedHashMap which examplifies the problem public void testIndexOf() throws Exception { Object[] keys = getKeys(); int expectedSize = keys.length; Object[] values = getValues(); for (int i = 0; i < expectedSize; i++) { labRat.put(keys[i], values[i]); } // test that the index returned are in the same order that they were // placed in the map for (int i=0;i<keys.length;i++) { assertEquals("indexOf with existing key failed",i,labRat.indexOf(keys[i])); } // test non existing key.. assertEquals("test with non-existing key failed",-1,labRat.indexOf ("NonExistingKey")); } |
17 years, 19 weeks, 1 day ago | 18970 | No Perforce job exists for this issue. | 0 | 13758 | 164680 | 0|i0sjrr: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-86 | LRUMap.get doesn't change usage status |
Bug | Closed | Major | Fixed | Unassigned | Frank Finger | Frank Finger | 17/Oct/02 14:48 | 18/Mar/20 02:50 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 2.0 | 0 | 0 | Operating System: All Platform: PC |
LRUMap drops the least resently added item, not the least recently used one. The following test fails in line 6 (and 7, if you comment out 6). 1: LRUMap map = new LRUMap( 2 ); 2: map.put( "2", "zwei" ); 3: map.put( "3", "drei" ); 4: map.get( "2" ); // now, "2" should be least recently used 5: map.put( "4", "vier" ); // this should drop "3" 6: assertEquals( "zwei", map.get("2") ); 7: assertEquals( null, map.get("3") ); 8: assertEquals( "vier", map.get("4") ); |
17 years, 24 weeks, 5 days ago | 18912 | No Perforce job exists for this issue. | 0 | 13722 | 164622 | 0|i0sjev: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-103 | SoftRefHashMap is all kinds of wonky |
Bug | Closed | Major | Fixed | Unassigned | Paul Jack | Paul Jack | 03/Jun/02 13:12 | 18/Mar/20 02:51 | 14/Jul/06 05:45 | 14/Jul/06 05:33 | 2.0 | 2.1 | 1 | 0 | Operating System: All Platform: All |
Many methods in SoftRefHashMap do not conform the the java.util.Map specification. After you populate a SoftRefHashMap using its put or putAll method, it transforms the values into SoftReferences. The get() method correctly re-translates the SoftReferences back into the actual object values, unless they've been garbage collected. However, the entrySet() collection view does NOT perform this reverse translation; iterating over an entry set gives you Map.Entry with SoftReference values. Since the equals() and hashCode() methods rely on iterating over the entry set, equals() and hashCode() are broken in SoftRefHashMap. Also, it's odd that after I put(key,value), containsValue(value) will return true, yet I won't be able to find the value in the entry set. Also, invoking setValue() on a Map.Entry in the entrySet will correctly update the map with a new value; however, the old value is not returned as per the Map specification. Also, the values() and entrySet() collection views are not backed by the map; alterations to the map are not reflected in any existing values() or entrySet() collection views. Also, containsKey(Object) is wierd. If I put(key,value), and the value is subsequently garbage collected, containsValue(value) will return false, yet containsKey(key) will still return true. Creating a values() collection view creates hard references to the map's values, essentially ruining the point of the class (so long as the values() collection view exists, the map does not function as a memory-aware cache). Finally, iterating over keySet() and entrySet() is wonky. Mappings might have been removed by the garbage collector, but the iterators will still return an object for the mapping. So keySet()'s iterator will return keys for values that aren't there anymore, and entrySet()'s iterator will return Map.Entries with keys that map to null instead of values. |
17 years, 34 weeks, 1 day ago | 18895 | No Perforce job exists for this issue. | 0 | 9571 | 164605 | 0|i0sjb3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-385 | Inconsistent Javadoc comment and code in addAll(Collection, Object[]) in org.apache.commons.collections.CollectionUtils |
Bug | Closed | Major | Not A Problem | Unassigned | SHIN HWEI TAN | SHIN HWEI TAN | 26/Oct/11 20:27 | 18/Mar/20 02:54 | 27/Nov/15 21:47 | 26/Jul/12 21:06 | 2.1, 2.1.1, 3.0, 3.1, 3.2 | Collection | 0 | 0 | 300 | 300 | 0% | Platform Independent | The Javadoc comment below states that the method "throws NullPointerException if the collection or array is null". /** * Adds all elements in the array to the given collection. * * @param collection the collection to add to, must not be null * @param elements the array of elements to add, must not be null * @throws NullPointerException if the collection or array is null */ public static void addAll(Collection collection, Object[] elements) { for (int i = 0, size = elements.length; i < size; i++) { collection.add(elements[i]); } } However, when called with an empty array and a null collection (i.e., "addAll((Collection)null, new Object[])"), the method executes normally without throwing any exception. Suggested Fixes: 1. Add code "if (collection == null) throw NullPointerException();" at the beginning of the method body. or 2. Remove "@throws NullPointerException if the collection or array is null" from the Javadoc. or 3. Change "@throws NullPointerException if the collection or array is null" to "@throws NullPointerException if the array is null or (the array is non-empty and the collection is null)". |
0% | 0% | 300 | 300 | javadoc, nullpointerexception | 8 years, 21 weeks, 3 days ago | 214816 | No Perforce job exists for this issue. | 0 | 164370 | 0|i0shuv: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-6 | [Collections] - MapUtils]Method to generate a Map from a Object[][] |
Bug | Closed | Major | Fixed | Unassigned | Rafael U. C. Afonso | Rafael U. C. Afonso | 27/Aug/04 08:02 | 18/Mar/20 02:51 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 2.1 | 0 | 0 | Operating System: other Platform: Other |
In Python Language it is possible create a dictionary (equivalent to Map) using only a single line: myMap = {'alpha':'a', 'betha':'b', 'gamma':'c'} In Java it is not possible. We must do it "manually": Map myMap = new HashMap(); myMap.put("alpha", "a"); myMap.put("betha", "b"); myMap.put("gamma", "c"); My propose is create a way to do this with less burocracy. In org.apache.commons.collections.MapUtils class could have a method called fillMap (or better name) that receives a Map and a bi-dimentional array of Objects. It will work like this: public static Map fillMap(Map map, Object[][] keyValue) { for(int i = 0; i < keyValue.length; i ++) { map.put(keyValue[i][0], keyValue[i][1]); } return map; } So, returning to prior example, we could do this: Map myMap = MapUtils.fillMap(new HashMap(), {{"alpha", "a"}, {"betha", "b"}, {"gama", "c"}}); Or to put in mass in a pre-existent MAP: MapUtils.fillMap(myMap, {{"delta", "d"}, {"epslon", "e"}, {"omega", "z"}}); |
15 years, 27 weeks, 5 days ago | 18992 | No Perforce job exists for this issue. | 1 | 30882 | 164702 | 0|i0sjwn: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-55 | [collections] Filling out PredicatedXXX Javadoc - a functor package.html |
Bug | Closed | Major | Fixed | Unassigned | Tim O'Brien | Tim O'Brien | 16/May/04 09:30 | 18/Mar/20 02:51 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 2.1 | 0 | 0 | Operating System: other Platform: Other |
In general Predicated collections and maps should probably be created before a data structure has any contents. Maybe this is just an artifact of the way I use PredicatedList, but, nevertheless, I think all of the PredicatedXXX classes need fuller JavaDoc - possibly pointing to an anchor in the package.html for the functors package that talks about some scenarios for using PredicatedXXX classes. Right now we don't have a good in JavaDoc explanation of the various ways to apply a Predicate to a collection. (I'm on a Javadoc kick, sorry.) |
15 years, 45 weeks, 3 days ago | 18943 | No Perforce job exists for this issue. | 0 | 29018 | 164653 | 0|i0sjlr: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-100 | [collections] IteratorChain bug with empty iterators. |
Bug | Closed | Major | Incomplete | Unassigned | Andrus Adamchik | Andrus Adamchik | 03/Dec/03 13:11 | 18/Mar/20 02:51 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 2.1 | 0 | 0 | Operating System: All Platform: All |
Haven't tried this with nightly builds, but 2.1 collections have the follwoing problem: when the first iterator in a chain is empty, first call to "hasNext" returns false, on second and subsequent calls, "true" is returned again as it should. Here is an example: List emptyList = new ArrayList(); List nonEmptyList = new ArrayList(); nonEmptyList.add(new Object()); IteratorChain it = new IteratorChain(new Iterator[] {emptyList.iterator(), nonEmptyList.iterator()}); System.out.println("Next? " + it.hasNext()); // prints false System.out.println("Next again? " + it.hasNext()); // prints true Cheers, Andrus |
16 years, 17 weeks, 4 days ago | 18898 | No Perforce job exists for this issue. | 0 | 25154 | 164608 | 0|i0sjbr: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-80 | [Patch] [Collections] ExtendedProperties.interpolate does not do recursive substitution |
Bug | Closed | Major | Fixed | Unassigned | hoschek | hoschek | 16/Dec/03 12:15 | 18/Mar/20 02:51 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 2.1 | 0 | 0 | Operating System: other Platform: Other |
[Patch] [Collections] ExtendedProperties.interpolate does not do recursive substitution in commons-collections-2.1, but it probably should, when used with getString(...). Example: firefish.home=/tmp/firefish database.dir=${firefish.home}/samples/cfengine database.file=${database.dir}/db.xml extendedProps.getString("database.file") I found out that this can be fixed with the patch below, which is simply a copy and paste from the CVS of org.apache.commons.configuration.AbstractConfiguration. /** * interpolate key names to handle ${key} stuff * * @param base string to interpolate * * @return returns the key name with the ${key} substituted */ protected String interpolate(String base) // copied from org.apache.commons.configuration.AbstractConfiguration { return (interpolateHelper(base, null)); } /** * Recursive handler for multple levels of interpolation. * * When called the first time, priorVariables should be null. * * @param base string with the ${key} variables * @param priorVariables serves two purposes: to allow checking for * loops, and creating a meaningful exception message should a loop * occur. It's 0'th element will be set to the value of base from * the first call. All subsequent interpolated variables are added * afterward. * * @return the string with the interpolation taken care of */ protected String interpolateHelper(String base, List priorVariables) // copied from org.apache.commons.configuration.AbstractConfiguration { if (base == null) { return null; } // on the first call initialize priorVariables // and add base as the first element if (priorVariables == null) { priorVariables = new ArrayList(); priorVariables.add(base); } int begin = -1; int end = -1; int prec = 0 - END_TOKEN.length(); String variable = null; StringBuffer result = new StringBuffer(); // FIXME: we should probably allow the escaping of the start token while (((begin = base.indexOf(START_TOKEN, prec + END_TOKEN.length())) > -1) && ((end = base.indexOf(END_TOKEN, begin)) > -1)) { result.append(base.substring(prec + END_TOKEN.length(), begin)); variable = base.substring(begin + START_TOKEN.length(), end); // if we've got a loop, create a useful exception message and throw if (priorVariables.contains(variable)) { String initialBase = priorVariables.remove(0).toString(); priorVariables.add(variable); StringBuffer priorVariableSb = new StringBuffer(); // create a nice trace of interpolated variables like so: // var1->var2->var3 for (Iterator it = priorVariables.iterator(); it.hasNext();) { priorVariableSb.append(it.next()); if (it.hasNext()) { priorVariableSb.append("->"); } } throw new IllegalStateException( "infinite loop in property interpolation of " + initialBase + ": " + priorVariableSb.toString()); } // otherwise, add this variable to the interpolation list. else { priorVariables.add(variable); } //QUESTION: getProperty or getPropertyDirect Object value = getProperty(variable); if (value != null) { result.append(interpolateHelper(value.toString(), priorVariables)); // pop the interpolated variable off the stack // this maintains priorVariables correctness for // properties with multiple interpolations, e.g. // prop.name=${some.other.prop1}/blahblah/${some.other.prop2} priorVariables.remove(priorVariables.size() - 1); } else if (defaults != null && defaults.getString(variable, null) != null) { result.append(defaults.getString(variable)); } else { //variable not defined - so put it back in the value result.append(START_TOKEN).append(variable).append(END_TOKEN); } prec = end; } result.append(base.substring(prec + END_TOKEN.length(), base.length())); return result.toString(); } |
16 years, 14 weeks, 1 day ago | 18918 | No Perforce job exists for this issue. | 0 | 25553 | 164628 | 0|i0sjg7: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-21 | TestMap.tearDown() should throw Exception |
Bug | Closed | Minor | Fixed | Unassigned | Rich Dougherty | Rich Dougherty | 01/Nov/02 07:20 | 18/Mar/20 02:51 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 2.1 | 0 | 0 | Operating System: other Platform: All |
TestMap.tearDown() overrides TestCase.tearDown(). The original method throws an Exception, however the redeclared method doesn't. This means that methods which override TestMap.tearDown() cannot throw an Exception. In my case, I'm creating and removing a test database in the setUp() and tearDown() so an Exception could easily be thrown. I realise that TestMap isn't part of Collections' public API, however I thought I'd mention this in case other people want to reuse your excellent testing code. |
17 years, 22 weeks, 3 days ago | 18977 | No Perforce job exists for this issue. | 0 | 14151 | 164687 | 0|i0sjtb: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-128 | [collections] IteratorChain - if first iterator empty, doesn't care about next ones. |
Bug | Closed | Major | Fixed | Unassigned | Pawel Stawicki | Pawel Stawicki | 10/Jan/04 21:27 | 18/Mar/20 02:51 | 15/Mar/08 21:36 | 14/Jul/06 12:04 | 2.1 | 1 | 0 | Operating System: All Platform: PC |
If first Iterator in IteratorChain is empty, and next ones contain some elements, first call to hasNext() on IteratorChain returns false. It should return true if there are elements in other Iterators. |
13 years, 37 weeks, 4 days ago | 18870 | No Perforce job exists for this issue. | 0 | 26038 | 164580 | 0|i0sj5j: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-96 | debug and verbose print in MapUtils only handles String keys |
Bug | Closed | Major | Fixed | Unassigned | Matt Gould | Matt Gould | 14/Jan/04 10:22 | 18/Mar/20 02:51 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 2.1 | 0 | 0 | Operating System: other Platform: All |
In MapUtils, if the key is e.g., Integer, fails with a ClassCastException: for ( Iterator iter = map.entrySet().iterator(); iter.hasNext(); ) { Map.Entry entry = (Map.Entry) iter.next(); ==> String childKey = (String) entry.getKey(); Object childValue = entry.getValue(); if ( childValue instanceof Map ) { verbosePrint( out, childKey, (Map) childValue ); } Should not be cast to a String, just use Object, and it works. Same thing goes for the less verbose sister method, debugPrint Thanks, Matt |
16 years, 11 weeks, 5 days ago | 18902 | No Perforce job exists for this issue. | 0 | 26115 | 164612 | 0|i0sjcn: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-50 | [collections] ExtendedProperties combine and pre unescaped strings-values |
Bug | Closed | Major | Won't Fix | Unassigned | Dean Arnold | Dean Arnold | 20/Nov/03 17:42 | 18/Mar/20 02:51 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 2.1 | 0 | 0 | Operating System: other Platform: All |
If you have 2 extended props (prop1 & prop2). prop1 contains some or none key/value pairs and prop2 contains at least one key with string value with commas that doesn't already exist in prop1. N.B. This assumes both props were loaded from property files and the string values in prop2 were escaped in the file-system properties. If you call prop1.combine(prop2), the string-value from prop2 that contained commas is treated as a non-escaped string and thus broken down into a Vector in prop1. It should put the string-value into prop1 without procing the commas as there were already processed by prop2 when it was loaded. I believe that the combine method should merge the existing values from both props and the putAll method should be overidden to overite existing keys in prop1 from prop2 while maintaining the keysAsListed List. |
16 years, 3 weeks, 2 days ago | 18948 | No Perforce job exists for this issue. | 0 | 24849 | 164658 | 0|i0sjmv: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-82 | [collections] Map.debugPrint improvements |
Bug | Closed | Major | Fixed | Unassigned | Max Rydahl Andersen | Max Rydahl Andersen | 13/Jun/03 18:07 | 18/Mar/20 02:51 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 2.1 | 0 | 0 | Operating System: other Platform: Other |
debugPrint and verbosePrint in MapUtils makes a cast of the key to a string (instead of calling toString() on it) which makes it impossible to use for debug printin maps with keys other than strings. |
16 years, 31 weeks, 2 days ago | 18916 | No Perforce job exists for this issue. | 5 | 20740 | 164626 | 0|i0sjfr: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-120 | BeanMap.toString() causes infinite loop on circular object graph |
Bug | Closed | Major | Fixed | Unassigned | _matthewHawthorne | _matthewHawthorne | 17/Apr/03 04:46 | 18/Mar/20 02:51 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 2.1 | 0 | 0 | Operating System: Linux Platform: Other |
This problem is similar to the one in [lang]'s ToStringBuilder. | 16 years, 50 weeks, 3 days ago | 18878 | No Perforce job exists for this issue. | 1 | 19096 | 164588 | 0|i0sj7b: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-2 | [collections] ExtendedProperties.save(...) does not escape special characters |
Bug | Closed | Major | Fixed | Unassigned | Dariusz Wojtas | Dariusz Wojtas | 16/Apr/03 18:28 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 2.1 | 0 | 0 | Operating System: All Platform: PC |
If some value ends with '\', then after saving it, load will fail or will have incorrect values. Try to store some property with value ending with '\', eg. path1=e:\ path2=c:\docs Look for java.util.Properties on escaping characters. |
16 years, 32 weeks, 2 days ago | 18996 | No Perforce job exists for this issue. | 1 | 19061 | 164706 | 0|i0sjxj: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-40 | ExtendedProperties.load should default to encoding "8859_1" |
Bug | Closed | Major | Fixed | Unassigned | Kirk Wolf | Kirk Wolf | 04/Mar/03 03:47 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 2.1 | 0 | 0 | Operating System: All Platform: All |
The default load method for commons.collections.ExtendedProperties currently loads properties using the default JVM encoding. The default load() method should use "8859_1" encoding. Rationale: 1) consistency: java.util.Properties.load() method always uses "8859_1" 2) properties resources are always 8859_1, by convention. 2) On edbcic machines, particularly IBM mainframes, the default encoding is Cp1047 (ebcdic), but properties files are always ASCII (ISO8859-1) 3) This bug causes many Apache tools, such as Velocity, which uses commons.collections, to fail on non-ascii machines, since they distribute properties resources which are (correctly) in 8859-1. |
16 years, 50 weeks, 3 days ago | 18958 | No Perforce job exists for this issue. | 1 | 17616 | 164668 | 0|i0sjp3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-105 | StaticBucketMap.remove(Object) incorrectly handles key comparison |
Bug | Closed | Major | Fixed | Unassigned | leo.sutic | leo.sutic | 18/Feb/03 02:15 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 2.1 | 0 | 0 | Operating System: other Platform: Other |
I've found a bug in the StaticBucketMap class, the remove(Object) method: /** * Implements {@link Map#remove(Object)}. */ public Object remove( Object key ) { int hash = getHash( key ); synchronized( m_locks[ hash ] ) { Node n = m_buckets[ hash ]; Node prev = null; while( n != null ) { HERE>>>>>>>>> if( n.key == null || ( n.key != null && n.key.equals( key ) ) ) <<<<<<<<<<<<<<<<<< { // Remove this node from the linked list of nodes. if( null == prev ) { // This node was the head, set the next node to be the new head. m_buckets[ hash ] = n.next; } else { // Set the next node of the previous node to be the node after this one. prev.next = n.next; } m_locks[hash].size--; return n.value; } prev = n; n = n.next; } } return null; } The test is: if( n.key == null || ( n.key != null && n.key.equals( key ) ) ) should be: if( n.key == key || ( n.key != null && n.key.equals( key ) ) ) which is how it works in get(Object), containsKey(Object) etc. and which is correct. We have a match if the keys match using == OR if they are equal according to equals(). |
17 years, 6 weeks, 3 days ago | 18893 | No Perforce job exists for this issue. | 0 | 17139 | 164603 | 0|i0sjan: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-91 | [collections] CollectionWrapper should implement Serializable |
Bug | Closed | Minor | Duplicate | Unassigned | sean schofield | sean schofield | 18/Nov/03 05:22 | 15/Mar/08 21:36 | 14/Jul/06 12:07 | 2.1 | 1 | 0 | Operating System: All Platform: All |
The CollectionWrapper inner class (part of CollectionUtils) should implement Serializable. This would allow the creation of serializable lists in the event that the user needs this functionality. Making this change would assume that all the objects contained in the list were serializable (not a big deal IMO.) I discovered this problem when using ListUtils.lazyList() method. The resulting list is not serializable and I need it to be. |
13 years, 37 weeks, 4 days ago | 18907 | No Perforce job exists for this issue. | 0 | 24762 | 164617 | 0|i0sjdr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-62 | ReferenceMap contract |
Bug | Closed | Major | Fixed | Unassigned | Eduardo Francos | Eduardo Francos | 27/Nov/02 17:50 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 2.1 | 0 | 0 | Operating System: All Platform: All |
I switched from SoftRefHashMap to ReferenceMap and I noticed that the purge method as become private and is called in many places in the source code, but the documentation for the method states that it is called only for write operations. I must be sure that the stale mappings are removed for read operations too (ex:size) and though currently the implementation calls purge() for all read methods as well this may change in the future. I think that calling purge on all [relevant] public methods is the right approach to preserve a coherent state. |
17 years, 10 weeks, 3 days ago | 18936 | No Perforce job exists for this issue. | 0 | 14889 | 164646 | 0|i0sjk7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-73 | BeanMap.putAllWriteable() does not count the write only methods |
Bug | Closed | Major | Fixed | Unassigned | Dimiter Dimitrov | Dimiter Dimitrov | 09/Jan/03 02:26 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 2.1 | 0 | 0 | Operating System: All Platform: All |
BeanMap.putAllWriteable(BeanMap) method, the java doc does not describe the implementation correctly. According to Sun a property could be defined by getter OR mutator. The current implementation of the method assumes that a property always should have getter. /** * Puts all of the writeable properties from the given BeanMap into this * BeanMap. Read-only properties will be ignored. */ public void putAllWriteable(BeanMap map) { Iterator readableKeys = map.readMethods.keySet().iterator(); while(readableKeys.hasNext()) { Object key = readableKeys.next(); if(getWriteMethod(key) != null) { this.put(key, map.get(key)); } } } I have an adapter bean which have a mutator which accepting a long value (actualy a bit vector) And few boolean accessors which retrieve the actual values. Now I'm replacing my own utility classes with jakarta commons and I find that these issues make them nearly unusable for me :( I suggest to change the method to: public void putAllWriteable(BeanMap map) { Iterator writableEntries = map.writeMethods.entrySet().iterator(); while(writableEntries.hasNext()){ Map.Entry writableEntry = (Map.Entry) writableEntries.next(); writeMethods.put(writableEntry.getKey(), writableEntry.getValue()); } } |
17 years, 10 weeks, 3 days ago | 18925 | No Perforce job exists for this issue. | 1 | 15897 | 164635 | 0|i0sjhr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-22 | [collections] In BeanMap all properties are writable (some with null mutator) |
Bug | Closed | Major | Fixed | Unassigned | Dimiter Dimitrov | Dimiter Dimitrov | 09/Jan/03 01:24 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 2.1 | 0 | 0 | Operating System: All Platform: All |
In BeanMap.initialize() method there is a bug that causes all properties to have write methods (even if they are null). |
15 years, 1 week, 6 days ago | 18976 | No Perforce job exists for this issue. | 1 | 15895 | 164686 | 0|i0sjt3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-734 | Encountered an IllegalStateException while traversing with Flat3Map.entrySet() |
Bug | Resolved | Major | Fixed | Unassigned | Chen | Chen | 11/Nov/19 08:07 | 05/Dec/19 16:13 | 05/Dec/19 16:13 | 3.0 | 4.5 | Map | 0 | 1 | 0 | 1200 | Encountered an IllegalStateException while traversing with Flat3Map.entrySet()
{code:java} //代码示例 public void testEntrySet() { final Flat3Map<Integer, String> map = new Flat3Map<>(); map.put(1, "A"); map.put(2, "B"); map.put(3, "C"); Iterator<Map.Entry<Integer, String>> it = map.entrySet().iterator(); Map.Entry<Integer, String> mapEntry1 = it.next(); Map.Entry<Integer, String> mapEntry2 = it.next(); Map.Entry<Integer, String> mapEntry3 = it.next(); it.remove(); assertEquals(2, map.size()); } {code} Using the above code will generate an IllegalStateException. The reason for this problem is that there is a problem with the EntryIterator.remove() method in the Flat3Map java class. I submitted a [PR|https://github.com/apache/commons-collections/pull/115](https://github.com/apache/commons-collections/pull/115) to fix this bug. |
100% | 100% | 1200 | 0 | 14 weeks, 5 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|z08gjk: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-580 | Arbitrary remote code execution with InvokerTransformer |
Bug | Closed | Major | Fixed | Unassigned | Philippe Marschall | Philippe Marschall | 07/Nov/15 13:28 | 18/Mar/20 02:57 | 24/Jul/19 18:56 | 21/Nov/15 10:02 | 3.0, 4.0 | 3.2.2, 4.1 | 66 | 104 | COLLECTIONS-583, VELTOOLS-169, COLLECTIONS-721, HADOOP-12579, IO-487, MYFACES-4020, KARAF-4135 | With {{InvokerTransformer}} serializable collections can be build that execute arbitrary Java code. {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes {{#entrySet}} and {{#get}} on a deserialized collection. If you have an endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you can combine the two to create arbitrary remote code execution vulnerability. I don't know of a good fix short of removing {{InvokerTransformer}} or making it not Serializable. Both probably break existing applications. This is not my research, but has been discovered by other people. https://github.com/frohoff/ysoserial http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ |
4 years, 15 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 1 | 9223372036854775807 | 0|i2o3kf: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-581 | Deserialization and Apache Commons Collection |
Bug | Closed | Major | Invalid | Mark Thomas | Deepesh | Deepesh | 10/Nov/15 09:55 | 18/Mar/20 02:55 | 27/Nov/15 21:47 | 10/Nov/15 10:00 | 3.0, 3.1, 3.2.1 | Functor | 0 | 1 | Hi Team, This is regarding “commons-collections Java library”. In our applications we are widely using this library and hence looking to urgently patch the fix for vulnerability issue if it is available. Searching on internet we found one patch released on Sunday 08th Nov http://svn.apache.org/viewvc?view=revision&revision=1713307 Just wanted to check with you if there is any updated / complied version of commons-collections jar available or going to be released soon which we can directly replace with our existing jar file that provides the fix for the vulnerability issue. Thanks in advance! |
patch | 4 years, 19 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 |
Patch, Important
|
0|i2o6qn: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-384 | Inconsistent Javadoc comment and code for synchronizedMap(Map) in org.apache.commons.collections.MapUtils |
Bug | Closed | Major | Fixed | Unassigned | SHIN HWEI TAN | SHIN HWEI TAN | 26/Oct/11 20:21 | 18/Mar/20 02:41 | 09/Nov/14 14:31 | 29/Oct/11 20:54 | 3.0, 3.1, 3.2 | 4.0-alpha1, 4.0 | Collection | 0 | 0 | 300 | 300 | 0% | Platform independent | The Javadoc comment below states that the method "throws IllegalArgumentException if the map is null": /** ... * @param map the map to synchronize, must not be null * @return a synchronized map backed by the given map * @throws IllegalArgumentException if the map is null */ public static Map synchronizedMap(Map map) { return Collections.synchronizedMap(map); } However, the method throws NullPointerException instead of IllegalArgumentException when called with null. Suggested Fixes: 1. Add code "if (map == null) throw IllegalArgumentException();" at the beginning of the method body. or 2. Change "@throws IllegalArgumentException if the map is null" to "@throws NullPointerException if the map is null". or 3. Remove the entire "@throws IllegalArgumentException if the map is null". |
0% | 0% | 300 | 300 | code, javadoc, synchronizedMap | 8 years, 21 weeks, 3 days ago | 214815 | No Perforce job exists for this issue. | 0 | 164371 | 0|i0shv3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-352 | AbstractCollectionDecorator is inconsistent with AbstractListDecorator. Uses private member variable instead of protected getter |
Bug | Closed | Minor | Fixed | Unassigned | Adam Gent | Adam Gent | 10/Feb/10 20:34 | 09/Nov/14 14:31 | 28/Feb/13 20:05 | 3.0, 3.1, 3.2 | 4.0-alpha1, 4.0 | Collection | 0 | 1 | AbstractListDecorator uses getList() to access its private member variable for its methods: {code} public int indexOf(Object object) { return getList().indexOf(object); } {code} Which allows me to almost do something like this (notice I'm taking some liberties here with the no-arg serialization constructor): {code} public static class FutureList<T> extends AbstractListDecorator { private Future<List<T>> futureList; public FutureList(Future<List<T>> futureList) { super(); this.futureList = futureList; } @Override protected Collection<T> getCollection() { try { return futureList.get(); } catch (InterruptedException e) { throw new RuntimeException(e); } catch (ExecutionException e) { throw new RuntimeException(e); } } } {code} But AbstractCollectionDecorator uses its private member variable {code} public boolean add(Object object) { return collection.add(object); } {code} When it should be IMHO: {code} public boolean add(Object object) { return getCollection().add(object); } {code} Of course most everybody has an armpit and an opinion :) |
9 years, 40 weeks, 3 days ago | 18651 | No Perforce job exists for this issue. | 0 | 164393 | 0|i0shzz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-98 | [collections] BlockingBuffer Should Include Cause Exception When Throwing BufferUnderflowException |
Bug | Closed | Major | Fixed | Unassigned | Seth Ladd | Seth Ladd | 23/Feb/05 06:22 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.0 | 0 | 0 | Operating System: All Platform: All |
The code for BlockingBuffer throws BufferUnderflowException when a InterruptedException is thrown. But, the original InterruptedException is not included or wrapped by the new BufferUnderflowException. This makes it difficult to determine if the thread was truly interrupted. I believe the commons project has support for wrapping exception (to support older JVMs). This would be very helpful to support. For instance, line 141 of the 3.0 version of BlockingBuffer. Thanks! |
14 years, 46 weeks, 1 day ago | 18900 | No Perforce job exists for this issue. | 0 | 33700 | 164610 | 0|i0sjc7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-118 | [collections] LRUMap.removeLRU(LinkEntry) is passed wrong link entry |
Bug | Closed | Major | Fixed | Unassigned | meurig sage | meurig sage | 16/Apr/04 20:51 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.0 | 0 | 0 | Operating System: Windows XP Platform: PC |
The following program attempts to add 3 entries (a,b,c) to an LRUMap with max size two. The contents of the LRUMap are always correct but when the LRUMap fills up it removes entry "a" but passes entry "b" to the removeLRU method. run: [java] [a] [java] [a, b] [java] Remove lru b [java] [b, c] import org.apache.commons.collections.map.LRUMap; public class LRUMapTest { public static void main (String[] args) { LRUMap map = new LRUMap(2) { protected boolean removeLRU(LinkEntry entry) { System.out.println("Remove lru "+entry.getKey()); return true; } }; map.put("a","a"); System.out.println(map.keySet()); map.put("b","b"); System.out.println(map.keySet()); map.put("c","c"); System.out.println(map.keySet()); } } |
15 years, 50 weeks, 3 days ago | 18880 | No Perforce job exists for this issue. | 0 | 28433 | 164590 | 0|i0sj7r: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-115 | Flat3Map doesn't implement Serializable |
Bug | Closed | Major | Fixed | Unassigned | Manik Surtani | Manik Surtani | 25/Mar/04 22:39 | 14/Jul/06 05:44 | 14/Jul/06 05:44 | 3.0 | 3.1 | 0 | 0 | Operating System: Linux Platform: All |
A very useful hish performance map. Sadly I cannot use it in my J2EE env because it isn't seriabilable and hence cannot be a parameter in any remote calls. Is there a specific reason as to why this isn't Serializable, or was this something that was overlooked? |
16 years, 4 days ago | 18883 | No Perforce job exists for this issue. | 0 | 27946 | 164593 | 0|i0sj8f: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-32 | [collections] DualTreeBidiMap does not sort with custom Comparator |
Bug | Closed | Major | Fixed | Unassigned | Jonas Van Poucke | Jonas Van Poucke | 11/Jun/04 15:47 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.0 | 3.1 | 0 | 0 | Operating System: other Platform: Other |
When you supply a Comparator to the constructor of DualTreeBidiMap, the custom sorting order is NOT maintained. The problem lies in the order where protected Map createMap() is called: The constructors in AbstractDualBidiMap call this metod, but the comparator is set *after* calling super() in DualTreeBidiMap: //--- Class AbstractDualBidiMap---// protected AbstractDualBidiMap() { super(); maps[0] = createMap(); maps[1] = createMap(); } //--- Class DualTreeBidiMap ---// public DualTreeBidiMap(Comparator comparator) { super(); this.comparator = comparator; // <-- Too late, createMap already called! } protected Map createMap() { return new TreeMap(comparator); // <-- Comparator always null } Hence, DualTreeBidiMap.compatator() always returns null. |
15 years, 42 weeks, 1 day ago | 18966 | No Perforce job exists for this issue. | 0 | 29519 | 164676 | 0|i0sjqv: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-81 | [collections] Open Patch 25553 for version 3.0 |
Bug | Closed | Major | Incomplete | Unassigned | Stefan DAMIAN | Stefan DAMIAN | 07/Jun/04 19:46 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.0 | 0 | 0 | Operating System: other Platform: Other |
Patch 25553 wasn't corrected in collection - final version 3.0 | 14 years, 40 weeks, 3 days ago | 18917 | No Perforce job exists for this issue. | 0 | 29423 | 164627 | 0|i0sjfz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-130 | [collections] CollectionUtils.cardinality should be made smarter about Bag |
Bug | Closed | Major | Fixed | Unassigned | Jon Schewe | Jon Schewe | 27/Apr/04 21:37 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.0 | 0 | 0 | Operating System: other Platform: Other |
I see that Bag implementations have a getCount() method that one would presume is more efficient than iterating over the objects in the Collection. Why doesn't CollectionUtils.cardinality() take advantage of this? |
15 years, 48 weeks, 6 days ago | 18868 | No Perforce job exists for this issue. | 0 | 28629 | 164578 | 0|i0sj53: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-24 | [collections] [patch] TransformingPredicate |
Bug | Closed | Major | Fixed | Unassigned | Alban Peignier | Alban Peignier | 15/Feb/04 05:47 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.0 | 0 | 0 | Operating System: other Platform: Other |
A Predicate which transforms the given object before evaluating the result with another Predicate : public boolean evaluate(Object object) { Object result = transformer.transform(object); return predicate.evaluate(result); } |
16 years, 3 weeks, 3 days ago | 18974 | No Perforce job exists for this issue. | 1 | 26946 | 164684 | 0|i0sjsn: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-27 | [collections] LRUMap.clone() broken? |
Bug | Closed | Major | Fixed | Unassigned | Fabrizio Giustina | Fabrizio Giustina | 23/Feb/04 22:21 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.0 | 0 | 0 | Operating System: other Platform: Other |
LRUMap.clone() always produces an empty Map. Shouldn't it produce a shallow copy with all the entries? This test actually fails in 3.0: public void testLRUMapClone() { LRUMap lru = new LRUMap(10); lru.put("1", "1"); Map lruClone = (Map) lru.clone(); assertEquals(lru.size(), lruClone.size()); } |
16 years, 5 weeks, 4 days ago | 18971 | No Perforce job exists for this issue. | 0 | 27159 | 164681 | 0|i0sjrz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-95 | [collections] fails the method TransformedMap.transformedMap |
Bug | Closed | Major | Fixed | Unassigned | Tirso Canela | Tirso Canela | 31/Aug/04 19:41 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.0 | 0 | 0 | Operating System: other Platform: Other |
This methods instance a TransformedMap but it doesn't do anything. The method transformMap must be called internally. |
14 years, 37 weeks, 3 days ago | 18903 | No Perforce job exists for this issue. | 1 | 30959 | 164613 | 0|i0sjcv: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-132 | Input streams are never closed in ExtendedProperties |
Bug | Closed | Major | Fixed | Unassigned | Lars Beuster | Lars Beuster | 17/Mar/04 20:59 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.0 | 0 | 0 | Operating System: other Platform: Other |
If I read a file with ExtendedProperties the OS cannot remove this file as long as my JVM is running because it has still a handle on that file. |
16 years, 2 weeks, 5 days ago | 18866 | No Perforce job exists for this issue. | 0 | 27737 | 164576 | 0|i0sj4n: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-599 | HashEntry array object naming data initialized with double the size during deserialization |
Bug | Closed | Critical | Fixed | Unassigned | Tejas Patel | Tejas Patel | 02/Dec/16 11:58 | 05/Jul/19 15:47 | 05/Jul/19 15:47 | 3.1 | 4.1 | Collection, Map | 0 | 4 | Common collections 3.1 and 3.2 are used at many places and frameworks including struts2.
Supose a LinkedMap object it is created and have size greater than zero is serialized. While deserializing this object , array of HashEntry naming data delacred in AbstractHashedMap always initialises with a new capacity of double its double of the serialized object. Please see the below API declared in AbstractHashedMap class : {code:java} protected void checkCapacity() { if (this.size >= this.threshold) { int newCapacity = this.data.length * 2; if (newCapacity <= 1073741824) { ensureCapacity(newCapacity); } } } {code} |
2 years, 6 weeks, 4 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 |
Important
|
0|i372nr: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-358 | CollectionUtils.removeAll(Collection collection, Collection remove) calls ListUtils.retainAll(collection, remove) |
Bug | Closed | Major | Duplicate | Unassigned | Andreas Knees | Andreas Knees | 29/Jun/10 21:35 | 29/Jun/10 23:38 | 29/Jun/10 23:38 | 3.1 | Collection | 0 | 0 | COLLECTIONS-357 | any | Inside CollectionUtils.removeAll(Collection collection, Collection remove) the retainAll() method of ListUtils is called in line 1122. It should read ListUtils.removeAll(collection, remove) instead. Workaround: use ListUtils.removeAll(Collection collection, Collection remove) instead. |
9 years, 39 weeks ago | 18645 | No Perforce job exists for this issue. | 0 | 164389 | 0|i0shz3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-250 | containsKey on MultiHashMap seems incorrect |
Bug | Closed | Critical | Invalid | James Carman | Nikhil G. Daddikar | Nikhil G. Daddikar | 27/Apr/07 10:24 | 15/Mar/08 21:36 | 30/Apr/07 10:56 | 3.1, 3.2 | Map | 0 | 2 | MultiHashMap m = new MultiHashMap(); m.putAll("key", Collections.EMPTY_LIST); System.out.println(m.containsKey("key")) It says false, when it should have printed true. The problem is that the code in MultiHashMap and even MultiValueMap has in putAll(): if (values == null || values.size() == 0) { return false; } This means that they key is never being entered into the Map. This is causing a huge problem because the behaviour has changed. |
12 years, 48 weeks, 1 day ago | 18749 | No Perforce job exists for this issue. | 0 | 164472 | 0|i0sihj: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-316 | LRUMap constructor javadoc and behavior are inconsistent (maxSize cannot be less than 0) |
Bug | Closed | Minor | Fixed | Unassigned | ori | ori | 10/Feb/09 21:55 | 09/Nov/14 14:31 | 28/Feb/13 20:04 | 3.1 | 4.0-alpha1, 4.0 | Map | 0 | 0 | 60 | 60 | 0% | n/a | The LRUMap constructor specifies "@param maxSize the maximum size of the map, -1 for no limit" The first line is then: if (maxSize < 1) { throw new IllegalArgumentException("LRUMap max size must be greater than 0"); } There is nothing wrong with allowing a negative maxSize. This way the map can be used to order elements relative to access time. I think the above code should be remove and the javadoc should stay the same. |
0% | 0% | 60 | 60 | 10 years, 44 weeks, 6 days ago | 18685 | No Perforce job exists for this issue. | 0 | 164421 | 0|i0si67: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-111 | IteratorChain skips over elements in iterator |
Bug | Closed | Major | Cannot Reproduce | Unassigned | Jonathan Giles | Jonathan Giles | 21/Jan/06 10:12 | 28/Feb/13 19:52 | 19/Mar/08 06:52 | 3.1 | Iterator | 0 | 0 | Operating System: Windows XP Platform: PC |
Hi there, When using the IteratorChain class to add multiple iterators, it appears that using itChain.hasNext() and itChain.next() skips a number of elements in the iterator at each step. Given a single iterator of 7 elements, and using the following code: private IteratorChain buildIterator() { // this iterator contains the children of the current object only Iterator it = getChildren(p); // we use an IteratorChain to add multiple iterators together without the overhead of copying IteratorChain itChain = new IteratorChain(it); return itChain; } and then simply IteratorChain it = treeModel.getAllTreeNodes(obj); // FIXME this only prints one or two of the results, which is a bug! while (it.hasNext()) System.out.println(": " + it.next().getClass()); I put in 7 elements, but only get 2 out - the 2nd and the last elements. It appears that through my debugging that the nextClause variable is updated even when the hasNext() function is called. Also, if I put 7 system.out.println statements, all elements are printed as normal. |
12 years, 1 week, 6 days ago | 18887 | No Perforce job exists for this issue. | 0 | 38341 | 164597 | 0|i0sj9b: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-69 | [collections] Comparable on AbstractKeyValue |
Bug | Closed | Major | Won't Fix | Unassigned | Shishir | Shishir | 03/Jan/05 01:54 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: All Platform: All |
Can either the AbstractKeyValue or DefaultKeyValue implement Comparable. Many a times, the KeyValue needs to be sorted on key,value and don't want to have screate a new Comparator in order to sort it |
15 years, 13 weeks ago | 18929 | No Perforce job exists for this issue. | 0 | 32914 | 164639 | 0|i0sjin: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-30 | [collections] TransformedMap.putAll fails with empty Map |
Bug | Closed | Major | Duplicate | Unassigned | Paul Libbrecht | Paul Libbrecht | 09/Feb/06 22:45 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: other Platform: Other |
Using collections 3.1, TransformedMap.putAll creates a new LinkedMap with the size of the parameter's collection as capacity. When this size is zero, however, this raises exceptions. paul |
14 years, 7 weeks, 5 days ago | 18968 | No Perforce job exists for this issue. | 0 | 38591 | 164678 | 0|i0sjrb: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-72 | [collections] java.lang.ArrayIndexOutOfBoundsException |
Bug | Closed | Major | Duplicate | Unassigned | Stijn Christiaens | Stijn Christiaens | 08/Feb/06 20:03 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.1 | 0 | 0 | Operating System: other Platform: Other |
In BoundedFifoBuffer (line 340): // Other elements require us to shift the subsequent elements int i = lastReturnedIndex + 1; while (i != end) { if (i >= maxElements) { elements[i - 1] = elements[0]; i = 0; } else { elements[i - 1] = elements[i]; i++; } } An AIOOBException is thrown at line 347 when trying to remove an element and i = 0. |
14 years, 7 weeks, 6 days ago | 18926 | No Perforce job exists for this issue. | 0 | 38565 | 164636 | 0|i0sjhz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-113 | [collections] ExtendedProperties#convertProperties doesn't inherit defaults. |
Bug | Closed | Major | Fixed | Unassigned | Shinobu Kawai | Shinobu Kawai | 13/Nov/04 00:44 | 02/May/13 02:28 | 15/Mar/08 21:36 | 3.1 | 0 | 0 | VELOCITY-333 | Operating System: other Platform: Other |
ExtendedProperties#convertProperties() uses props.keys() instead of props.propertyNames(), causing the defaults properties to be discarded. |
14 years, 45 weeks, 1 day ago | 18885 | No Perforce job exists for this issue. | 2 | 32204 | 164595 | 0|i0sj8v: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-18 | [collections] ListOrderedSet broken or documentation wrong. |
Bug | Closed | Minor | Fixed | Unassigned | Rohan Lenard | Rohan Lenard | 05/Nov/04 08:45 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: other Platform: All |
The method ListOrderedSet.decorate(List list) "decorates" the list, implying that it leaves the underlying list un-modified. But this is just not true - it requires a modifiable List so it can remove duplicates. It should at least warn about this - so you don't have to look in the code to see how it works and see why it fails when using an unmodifiable list (such as given by java.util.Collections.unmodifiableList()). Actually it'd be good to have a variant that worked with unmodifiable lists. |
15 years, 13 weeks ago | 18980 | No Perforce job exists for this issue. | 0 | 32073 | 164690 | 0|i0sjtz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-61 | [collections] FilterIterator doesn't reset when properties are set |
Bug | Closed | Major | Fixed | Unassigned | Huw Roberts | Huw Roberts | 30/Dec/05 05:14 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: other Platform: Other |
Test case follows: [pre] /** * Test that when the iterator is changed, the hasNext method * returns the correct response for the new iterator. */ public void testSetIterator() { Iterator iter1 = Collections.singleton(new Object()).iterator(); Iterator iter2 = Collections.EMPTY_LIST.iterator(); FilterIterator filterIterator = new FilterIterator(iter1); filterIterator.setPredicate(TruePredicate.getInstance()); assertTrue("filterIterator should have an element", filterIterator.hasNext()); filterIterator.setIterator(iter2); assertTrue("filterIterator should not have an element", ! filterIterator.hasNext()); } /** * Test that when the predicate is changed, the hasNext method * returns the correct response for the new predicate. */ public void testSetPredicate() { Iterator iter = Collections.singleton(null).iterator(); FilterIterator filterIterator = new FilterIterator(iter); filterIterator.setPredicate(TruePredicate.getInstance()); assertTrue("filterIterator should have an element", filterIterator.hasNext()); filterIterator.setPredicate(NotNullPredicate.getInstance()); assertTrue("filterIterator should not have an element", ! filterIterator.hasNext()); } [/pre] |
14 years, 12 weeks, 3 days ago | 18937 | No Perforce job exists for this issue. | 0 | 38074 | 164647 | 0|i0sjkf: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-38 | [collections] Javadoc entry page overview has bad links for 'Transformer' and 'Factory' |
Bug | Closed | Trivial | Fixed | Unassigned | andreas przygienda | andreas przygienda | 02/Jun/05 22:04 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: All Platform: All |
the overview in the entry page of the collections API javadoc has bad links in the description of the "org.apache.commons.collections.functors" package. (*...* means an underlying link): "This package contains implementations of the *Closure*, *Predicate*, *Transformer* and *Factory* interfaces." *Transformer* and *Factory* link to the Predicate Interface |
14 years, 43 weeks ago | 18960 | No Perforce job exists for this issue. | 0 | 35186 | 164670 | 0|i0sjpj: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-33 | [collections] AbstractHashedMap: initial threshold too conservative |
Bug | Closed | Major | Fixed | Unassigned | Christian Siefkes | Christian Siefkes | 23/May/05 00:28 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: other Platform: All |
The (int initialCapacity, float loadFactor) constructor of org.apache.commons.collections.map.AbstractHashedMap calculates the initial resize too threshold conservatively, based on the requested initial capacity instead of the actually chosen initial capacity (which is round up to the next power of too). This could be fixed switching two lines to calculating the initial threshold after rounding up the capacity instead of before: --- AbstractHashedMap.java 2005-05-22 17:04:23.000000000 +0200 +++ AbstractHashedMap-patched.java 2005-05-22 17:08:46.000000000 +0200 @@ -147,4 +147,4 @@ this.loadFactor = loadFactor; - this.threshold = calculateThreshold(initialCapacity, loadFactor); initialCapacity = calculateNewCapacity(initialCapacity); + this.threshold = calculateThreshold(initialCapacity, loadFactor); this.data = new HashEntry[initialCapacity]; A map with an requested capacity of 600 and a load factor of 0.75, will start with an initial array of length 1024. Without the fix, the array will be resized for the first time as soon as there are 450 entries, i.e. the array is less than 45% filled instead of the 75% suggested by the load factor. |
14 years, 45 weeks, 2 days ago | 18965 | No Perforce job exists for this issue. | 0 | 35012 | 164675 | 0|i0sjqn: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-70 | [collections] TreeList Collections.binarySearch problem - general remove() after previous() problem |
Bug | Closed | Major | Fixed | Unassigned | Tomas D. | Tomas D. | 08/Jun/05 06:21 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.1 | 0 | 0 | Operating System: Windows XP Platform: Other |
Sometimes TreeList crashes if i tried to call: Collections.binarySearch(queue, n, comp); with ArrayList is everything ok. Exception in thread "main" java.lang.NullPointerException at org.apache.commons.collections.list.TreeList$TreeListIterator.previous (TreeList.java:841) at java.util.Collections.get(Unknown Source) at java.util.Collections.iteratorBinarySearch(Unknown Source) at java.util.Collections.binarySearch(Unknown Source) at utils.queue.QueueSorted.put(QueueSorted.java:51) at framework.search.GraphSearch.solve(GraphSearch.java:53) at search.informed.BestFirstSearch.solve(BestFirstSearch.java:20) at Hlavni.main(Hlavni.java:66) |
14 years, 10 weeks, 3 days ago | 18928 | No Perforce job exists for this issue. | 3 | 35258 | 164638 | 0|i0sjif: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-12 | ListOrderedSet add results in separate objects in set/list if equal |
Bug | Closed | Major | Cannot Reproduce | Stephen Colebourne | Gene Hart | Gene Hart | 03/Nov/05 07:59 | 19/Jul/06 22:01 | 19/Jul/06 22:01 | 3.1 | Set | 0 | 0 | Operating System: other Platform: Other |
If you add an object to ListOrderedSet, and then try to replace the object with add and the objects are different but equals() is true, you will have two different objects in the internal list and set so after you do an add, doing a listorderedset.get(i) will return the old object. |
13 years, 36 weeks, 6 days ago | 18986 | No Perforce job exists for this issue. | 0 | 37338 | 164696 | 0|i0sjvb: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-93 | [collections] When the AbstractHashedMap is serialized and deserialized the data array doubles its size |
Bug | Closed | Major | Fixed | Unassigned | Marcos Cesar de Oliveira | Marcos Cesar de Oliveira | 02/Apr/05 03:19 | 15/Mar/08 21:36 | 14/Jul/06 12:04 | 3.1 | 1 | 0 | Operating System: Windows XP Platform: PC |
In the method "AbstractHashMap#doReadObject", the method call "threshold = calculateThreshold(data.length, loadFactor);" is after the "put(key, value);". The "put" method uses the threshold to check the capacity of the data array. In this checking, the threshold is zero, leading to a resize of the data array. At each serialization/deserialization the size of the data array doubles. |
13 years, 37 weeks, 4 days ago | 18905 | No Perforce job exists for this issue. | 0 | 34265 | 164615 | 0|i0sjdb: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-77 | [collections] IteratorChain.remove() in combination with FilterIterator |
Bug | Closed | Major | Fixed | Unassigned | Peter Billen | Peter Billen | 02/Apr/05 03:52 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.1 | 0 | 0 | Operating System: Windows XP Platform: Other |
IteratorChain.remove() throws IllegalStateException when one of the underlying iterators is a FilterIterator code: http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgNo=64950 |
14 years, 46 weeks ago | 18921 | No Perforce job exists for this issue. | 2 | 34267 | 164631 | 0|i0sjgv: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-49 | [collections] Compile Errors when Importing in VAJ 4 |
Bug | Closed | Major | Won't Fix | Unassigned | David Müller | David Müller | 08/Apr/05 18:48 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: Windows 2000 Platform: PC |
Hi, when I try to import Collections Framework into IBM VisualAge for Java (VAJ) 4, I get loads of Compile Errors. (For your information: VAJ is Java 1.2.2 based...) Most Errors are in the Testing Framework, so could be ignored. However, there are quite a few Errors from using Entry instead of Map.Entry, for Example in AbstractReferenceMap public Object get(Object key) { purgeBeforeRead(); Entry entry = getEntry(key); if (entry == null) { return null; } return entry.getValue(); } It would be nice for less adventurous users not to have to change the source code in order to use this in VAJ. I can send you the changed sources. Yours, David P.S.: The severity "major" is debatable... 8-) |
14 years, 45 weeks, 1 day ago | 18949 | No Perforce job exists for this issue. | 0 | 34368 | 164659 | 0|i0sjn3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-88 | [collection] Map filter with MapUtils.predicatedMap feature request |
Bug | Closed | Major | Won't Fix | Unassigned | Luc Carpentier | Luc Carpentier | 14/Apr/05 15:32 | 03/May/11 00:36 | 15/Mar/08 21:36 | 3.1 | 0 | 0 | Operating System: other Platform: Other |
Hello, I stumbled into the following problem: A client submits an http request with prefixed parameters. Each prefix will have it's own javabean to populate. So if there are two prefixes, then there will be two different javabeans to populate from the request parameters. I created a PrefixPredicate that only allows values with a specific prefix. I then used this PrefixPredicate to copy the Map with the request parameters to a predicated Map with: Map predicatedMap = MapUtils.predicatedMap(dataMap,keyPredicate,null); However, since the request parameters contain parameters with other prefixes as well, this returns an IllegalArgumentException. It would be nice to be able to specify to the MapUtils.predicatedMap method to ignore entries that do not comply to the predicate instead of to throw an exception. There are lots of possabilities to filter on a Collection, but a Map is not a collection... |
8 years, 47 weeks, 1 day ago | 18910 | No Perforce job exists for this issue. | 0 | 34446 | 164620 | 0|i0sjef: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-3 | NPE: map.LRUMap.reuseMapping(LRUMap.java:272) |
Bug | Closed | Major | Cannot Reproduce | Unassigned | Otis Gospodnetic | Otis Gospodnetic | 08/Dec/04 03:39 | 28/Feb/13 19:53 | 17/Jun/09 09:48 | 3.1 | Map | 2 | 0 | COLLECTIONS-330 | Operating System: Linux Platform: PC |
I'm using Collections 3.1 and just found this NPE in my logs: java.lang.NullPointerException at org.apache.commons.collections.map.LRUMap.reuseMapping(LRUMap.java:272) at org.apache.commons.collections.map.LRUMap.addMapping(LRUMap.java:243) at org.apache.commons.collections.map.AbstractHashedMap.put(AbstractHashedMap.java:282) I instantiated LRUMap like this: LRUMap map = new LRUMap(31); And from there on, I use it like I'd use any Map, putting things into it, and so on. Maybe I'm not using LRUMap correctly? My _guess_ is that this occurs when the Map is full, but I am not certain. I am wrapping the LRUMap in my own Maps as follows, but I think they're not the culprit: LRUMap map = new LRUMap(31); _userSessions = new ExpiringMap(map, new TimerTTLReferenceHolder(1800000), // ttl=30min 300000); // purge frequency=5min The only similar thing I found is COM-1288, but it looks like that was fixed before 3.1 release. I understand the value of a self-contained unit test that demonstrates this bug, but it happens only occassionally on my production system, never during development, so I can't really come up with it :( My guess is that this is a boundary case, as line 272 is: loop = loop.next; So 'loop' is most likely null, and it's null because ... not sure, maybe that hashIndex is wrong. |
10 years, 40 weeks, 6 days ago | 18995 | No Perforce job exists for this issue. | 3 | 32573 | 164705 | 0|i0sjxb: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-123 | [collections] StaticBucketMap#containsKey(final Object key) can return illegal value. |
Bug | Closed | Major | Fixed | Unassigned | Kazuya Ujihara | Kazuya Ujihara | 20/Nov/05 18:18 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.1 | 0 | 0 | Operating System: Windows XP Platform: All |
org.apache.commons.collections.map.StaticBucketMap#containsKey("any string") can return true by mistake when null key is containing in buckets. I think containsKey(Object) method has to be modified like the following. public boolean containsKey(final Object key) { int hash = getHash(key); synchronized (locks[hash]) { Node n = buckets[hash]; while (n != null) { - if (n.key == null || (n.key != null && n.key.equals(key))) { + if ((n.key == null && key == null) || (n.key != null && n.key.equals(key))) { return true; } n = n.next; } } return false; } Kazuya Ujihara |
14 years, 18 weeks, 6 days ago | 18875 | No Perforce job exists for this issue. | 0 | 37567 | 164585 | 0|i0sj6n: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-134 | [collections] Error in deserialization of full BoundedFifoBuffer |
Bug | Closed | Major | Duplicate | Unassigned | Tilmann Kuhn | Tilmann Kuhn | 17/Nov/05 07:52 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.1 | 0 | 0 | Operating System: All Platform: All |
If a BoundedFifoBuffer is serialized and then deserialized the value of the end attribute is set to the max size of the Buffer which is a fault and causes an ArrayIndexOutOfBoundException during add(object). In this case the value of end must be set to 0 in the deserialization. |
14 years, 19 weeks ago | 18864 | No Perforce job exists for this issue. | 0 | 37539 | 164574 | 0|i0sj47: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-11 | [Collections] LazyList throws IndexOutOfBoundsException when trying to set a value out of list bounds |
Bug | Closed | Major | Cannot Reproduce | Unassigned | Heston Fernandes | Heston Fernandes | 11/Nov/05 01:05 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: Windows XP Platform: PC |
This was discovered when using struts 1.2.7 with dynamic forms (Tomcat 5.0.24, jdk 1.4.2). The reset() method in the ActionForm used LazyList.decorate(). if(rooms==null) { rooms = new ArrayList(); roomPrefs.add("-"); roomPrefs = LazyList.decorate(roomPrefs, factory); } However after reset() I get the error below when it tries to initialize the ArrayList. IndexOutOfBoundsException -> Index: 1, Size: 1 java.lang.IndexOutOfBoundsException: Index: 1, Size: 1 at java.util.ArrayList.RangeCheck(ArrayList.java:507) at java.util.ArrayList.set(ArrayList.java:340) at org.apache.commons.collections.list.AbstractListDecorator.set(AbstractListDecorator.java:97) at org.apache.commons.beanutils.PropertyUtilsBean.setIndexedProperty(PropertyUtilsBean.java:1417) at org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:1016) at org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:811) at org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:298) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:493) at org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:805) at .... Possible Solution: For now I've created a class similar to LazyList and have overridden the set(object, element) method and it has worked. public Object set(int index, Object element) { int size = list.size(); // Grow the list if (index >= size) { for (int i = size; i <= index; i++) { list.add(null); } } return list.set(index, element); } I'm not sure if I'm using LazyList the right way but thought I'd bring it to your attention. Thanks! |
14 years, 20 weeks, 4 days ago | 18987 | No Perforce job exists for this issue. | 0 | 37450 | 164697 | 0|i0sjvj: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-101 | [collections] CursorableLinkedList iteration broken with previous |
Bug | Closed | Major | Fixed | Unassigned | Stephen Colebourne | Stephen Colebourne | 16/Jul/05 23:14 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.1 | 0 | 0 | Operating System: All Platform: All |
With a CursorableLinkedList, if you perform a Next, Next, Previous on an iterator/cursor, then remove the last object returned by index from the list, you will leave the cursor in an invalid state. You should at this point not be able to call remove/set on the iterator, but you can. |
14 years, 37 weeks, 3 days ago | 18897 | No Perforce job exists for this issue. | 0 | 35766 | 164607 | 0|i0sjbj: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-42 | [collections] PriorityBuffer iterator does not remove elements properly |
Bug | Closed | Major | Cannot Reproduce | Unassigned | Dusan Chromy | Dusan Chromy | 02/Mar/05 01:11 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: All Platform: All |
The following code snippet: System.out.println("----------"); PriorityBuffer s = new PriorityBuffer(); s.add(new Integer(1)); s.add(new Integer(2)); s.add(new Integer(3)); for (Iterator it = s.iterator(); it.hasNext(); s.remove() ) System.out.println(it.next()); System.out.println("----------"); Prints this: ---------- 1 3 ---------- Element 2 is lost, contrary to javadoc of java.util.Iterator |
15 years, 1 week, 6 days ago | 18956 | No Perforce job exists for this issue. | 0 | 33791 | 164666 | 0|i0sjon: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-75 | [collections] PriorityBuffer ignores natural order of elements |
Bug | Closed | Blocker | Incomplete | Unassigned | Dusan Chromy | Dusan Chromy | 01/Mar/05 23:52 | 16/May/06 12:16 | 16/May/06 12:16 | 3.1 | 0 | 0 | Operating System: All Platform: All |
The following code snippet: ------------------------------- PriorityBuffer r = new PriorityBuffer(); r.add(new Integer(2)); r.add(new Integer(1)); r.add(new Integer(0)); for (Iterator it = r.iterator(); it.hasNext(); ) System.out.println(":"+it.next()); ------------------------------- Prints this :0 :2 :1 |
15 years, 5 weeks ago | 18923 | No Perforce job exists for this issue. | 0 | 33788 | 164633 | 0|i0sjhb: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-124 | [collections][PATCH] SetUniqueList breaks when swapping entries |
Bug | Closed | Major | Fixed | Unassigned | Tom Dunham | Tom Dunham | 29/Jan/05 04:15 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.1 | 0 | 0 | Operating System: All Platform: PC |
If you create a SetUniqueList with two entries a and b: [a,b] Then you do: Object a = l.get(0); l.set(0, b) l.add(0, a); You expect to have swapped the two entries. But you get [b] Which seems to be wrong. |
15 years, 8 weeks, 4 days ago | 18874 | No Perforce job exists for this issue. | 3 | 33294 | 164584 | 0|i0sj6f: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-36 | [collections] MultiHashMap.remove(key, value) always returns a value |
Bug | Closed | Major | Fixed | Unassigned | Tad Marko | Tad Marko | 24/Nov/04 06:01 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: Linux Platform: PC |
According to the documentation, MultiHashMap.remove(key, value) will only return a value when it removes a value, null if nothing was removed. Instead, it always returns a value. |
15 years, 13 weeks ago | 18962 | No Perforce job exists for this issue. | 0 | 32366 | 164672 | 0|i0sjpz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-53 | [collections] Iterator.remove() in UnboundedFifoBuffer does not work |
Bug | Closed | Major | Fixed | Unassigned | Andreas Schlosser | Andreas Schlosser | 14/Jul/05 18:29 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: All Platform: All |
The implementation of Iterator.remove() in the unbounded fifo buffer is buggy. It produces an ArrayIndexOutOfBoundExceptions when it needs to swap around the end of the array to its start. The code should be: public void remove() { if (lastReturnedIndex == -1) { throw new IllegalStateException(); } // First element can be removed quickly if (lastReturnedIndex == head) { UnboundedFifoBuffer.this.remove(); lastReturnedIndex = -1; return; } // Other elements require us to shift the subsequent elements /* * This loop is buggy in the original implementation! */ int i = lastReturnedIndex + 1; while (i != tail) { buffer[decrement(i)] = buffer[i]; i = increment(i); } lastReturnedIndex = -1; tail = decrement(tail); buffer[tail] = null; index = decrement(index); } while the original buggy loop is: // Other elements require us to shift the subsequent elements int i = lastReturnedIndex + 1; while (i != tail) { if (i >= buffer.length) { buffer[i - 1] = buffer[0]; i = 0; } else { buffer[i - 1] = buffer[i]; i++; } } |
14 years, 37 weeks, 3 days ago | 18945 | No Perforce job exists for this issue. | 0 | 35733 | 164655 | 0|i0sjm7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-14 | [collections] Missing putAll(Map map) in MultiHashMap since 3.1 |
Bug | Closed | Major | Fixed | Unassigned | Sven Macke | Sven Macke | 06/Jul/05 23:44 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: Windows 2000 Platform: PC |
I just upgraded to version 3.1 and noticed some errors in my application. The cause is the method putAll(Map map) I used to call on a MultiHashMap to copy to content of one to another. That method is not defined in MultiHashMap any more, so HashMap.putAll(Map map) is used. The result of that is a MultiHashMap that contains ONE value per key and the value itself is a Collection. Here is some test code I would expect to work, but it fails: public class MultiHashMapTest extends TestCase { public void testIt() { MultiMap original = new MultiHashMap(); original.put("key", "object1"); original.put("key", "object2"); MultiMap copy = new MultiHashMap(); copy.putAll(original); assertEquals(original.values().size(), copy.values().size()); assertTrue(copy.containsValue("object1")); assertTrue(copy.containsValue("object2")); } } |
14 years, 37 weeks, 2 days ago | 18984 | No Perforce job exists for this issue. | 0 | 35631 | 164694 | 0|i0sjuv: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-64 | [collections] UnboundedFifoBuffer deserialization is broken |
Bug | Closed | Major | Fixed | Unassigned | Stephen Colebourne | Stephen Colebourne | 16/Jul/05 20:24 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: All Platform: All |
The patch should be: private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException { in.defaultReadObject(); int size = in.readInt(); - buffer = new Object[size]; + buffer = new Object[size + 1]; for (int i = 0; i < size; i++) { buffer[i] = in.readObject(); } head = 0; tail = size; } Setting tail = size - 1; just caused another bug (ie you couldn't get the last element in the buffer). This is because tail is supposed to point to the next unused cell in the buffer array. By creating the buffer to be size + 1, tail will be set to a valid cell within buffer that is empty (but the cell before it has an element in it), and the class works properly. Thomas Knych, Jordan Krey & Citigroup Analytics Dev team |
14 years, 37 weeks, 3 days ago | 18934 | No Perforce job exists for this issue. | 0 | 35763 | 164644 | 0|i0sjjr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-107 | [collections] AbstractMapBag.BagIterator.remove broken |
Bug | Closed | Major | Fixed | Unassigned | Stephen Colebourne | Stephen Colebourne | 15/Jul/05 08:07 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.1 | 0 | 0 | Operating System: All Platform: All |
I can't get in to CVS to see if this is fixed, but there is a bug in AbstractMapBag in 3.1: BagIterator.remove() does not properly remove the last instance of a given item; the result is infinite looping. Here is a patch. -steve Steve Clark ECOS Development Group steve_clark@fws.gov (970)226-9291 --- AbstractMapBag.java.orig 2005-07-14 11:14:33.708373173 -0600 +++ AbstractMapBag.java 2005-07-14 11:15:30.566623793 -0600 @@ -221,7 +221,7 @@ throw new IllegalStateException(); } MutableInteger mut = (MutableInteger) current.getValue(); - if (mut.value > 0) { + if (mut.value > 1) { mut.value--; parent.size--; } else { |
14 years, 37 weeks, 4 days ago | 18891 | No Perforce job exists for this issue. | 0 | 35747 | 164601 | 0|i0sja7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-104 | [collections] Only last element is removeable when CircularFifoBuffer is full |
Bug | Closed | Major | Fixed | Unassigned | Amir Tahvildaran | Amir Tahvildaran | 13/Jan/05 03:30 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.1 | 0 | 0 | Operating System: Linux Platform: PC |
If the circular fifo buffer is full and you remove an item, that is not the last one, it breaks. code example: import java.io.*; import org.apache.commons.collections.buffer.*; class Stub { public static void main(String[] args) { CircularFifoBuffer fifo = new CircularFifoBuffer(5); System.out.println(fifo); fifo.add(new String("1")); System.out.println(fifo); fifo.add(new String("2")); System.out.println(fifo); fifo.add(new String("3")); System.out.println(fifo); fifo.add(new String("4")); System.out.println(fifo); System.out.println("adding 5"); fifo.add(new String("5")); System.out.println(fifo); String six = new String("6"); System.out.println("adding 6"); fifo.add(six); System.out.println(fifo); /* uncomment the following block to avoid problem System.out.println("fifo.isFull?:"+fifo.isFull()); System.out.println("removing 6"); fifo.remove(new String("6")); System.out.println(fifo); */ System.out.println("fifo.isFull?:"+fifo.isFull()); System.out.println("removing 3"); fifo.remove(new String("3")); System.out.println(fifo); System.out.println("removing 4"); fifo.remove(new String("4")); System.out.println(fifo); System.out.println("clearing"); fifo.clear(); System.out.println("removing 4"); fifo.remove(new String("4")); System.out.println(fifo); } } ============== output busted: [] [1] [1, 2] [1, 2, 3] [1, 2, 3, 4] adding 5 [1, 2, 3, 4, 5] adding 6 [2, 3, 4, 5, 6] fifo.isFull?:true removing 3 Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1 at org.apache.commons.collections.buffer.BoundedFifoBuffer$1.remove(BoundedFifoBuffer.java:347) at java.util.AbstractCollection.remove(AbstractCollection.java:255) at Stub.main(Stub.java:40) |
14 years, 7 weeks, 6 days ago | 18894 | No Perforce job exists for this issue. | 0 | 33071 | 164604 | 0|i0sjav: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-85 | ReferenceMap clears bindings too early |
Bug | Closed | Major | Invalid | Unassigned | Eric Bodden | Eric Bodden | 04/Mar/06 15:58 | 07/Aug/06 21:08 | 07/Aug/06 21:08 | 3.1 | Map | 0 | 0 | Operating System: Windows XP Platform: Other |
Hello. This week I had to debug some small example program we are currently working on and it really took me a long time to find the actual problem because apprently there seems to be a bug in the implementation of ReferenceMap, which was really very unexpected for me. To me this seems very critical because I reckon that the ReferenceMap is in wide use. Hence I am describing my findings in detail. The code is AspectJ code, but I also provide the bytecode. The puspose of the code is to detect the so-called "lock order reversal pattern", a temporal event pattern which gives indication of potentially unsafe locking. It tries to detect patterns where a thread t1 tries to acquire locks in the order l1 l2 and another thread t2 tries to do so in the order r2 r1. When you compile the attached code with the AspectBench compiler (www. aspectbench.org) and then execute "java LORTest", depending on the map implementation you choose, one of the following traces is produced: - "log": your commons impl. (Reference identity map with weak key and values) - "log_jre": the JRE impl. (hash map with weak keys, no identity map, but does not matter since the keys are threads, which do not implement equals(...)) (Both logs are also in the tarball.) In log_jre you see that the LOR is detected (at the bottom). That works as follows: Whenever a lock is taken, the relationship (thread,lock) is put into a first (weak) map (see logging points "Xa"). Also, for all such relations which are contained already, we put a reference to a pair (thread,(lock1,lock2)) into a second map (logging points "Xb"). This represents the information "thread" took first "lock1" then "lock2". As "log" shows, the weak map by commons is looses all the sudden some bindings. (Compare to log_jre.) This seems really buggy, since subsequent logging output shows that the threads and locked resources still exist! For me this is fully deterministically reproducable. I am using Windows XP with this JRE: java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) You can compile the code (using the AspectBench compiler) with "compile.bat" or you can just run it with "run.bat", if you like. |
13 years, 34 weeks, 2 days ago | 18913 | No Perforce job exists for this issue. | 1 | 38853 | 164623 | 0|i0sjf3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-51 | [collections] LRUMap loses values when resizing. |
Bug | Closed | Critical | Incomplete | Unassigned | Dave Dandeneau | Dave Dandeneau | 23/Feb/06 01:15 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: Windows XP Platform: PC |
I am using the LRUMap and I have noticed that when it resizes the Map it loses the values that were in it previously. I noticed this when it was resizing my map from size of 2 to size of 4. |
14 years, 5 weeks, 6 days ago | 18947 | No Perforce job exists for this issue. | 0 | 38753 | 164657 | 0|i0sjmn: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-67 | [collections] PriorityBuffer does not implement Serializable |
Bug | Closed | Minor | Fixed | Unassigned | Steve Phelps | Steve Phelps | 12/Aug/05 23:42 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: other Platform: Other |
The class org.apache.commons.collections.buffer.PriorityBuffer does not implement java.io.Serializable |
14 years, 25 weeks, 3 days ago | 18931 | No Perforce job exists for this issue. | 2 | 36163 | 164641 | 0|i0sjj3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-48 | [collections] TransformedMap putAll(empty map) causes IllegalArgumentException |
Bug | Closed | Major | Fixed | Unassigned | Marc Lottman | Marc Lottman | 30/Apr/05 06:33 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: Windows XP Platform: PC |
If you create a TransformedMap, and then call map.putAll with an empty map as an argument, an IllegalArgumentException is thrown. putAll should be able to handle empty maps without erroring. The error occurs regardless of whether the decorated map has any contents. The implementation of the Transformers attached does not matter. I am using Java 1.4.2_07. Example code: Map map = TransformedMap.decorate( new HashMap(), TransformerUtils.nopTransformer(), TransformerUtils.nopTransformer()); map.putAll(new HashMap()); // This causes IllegalArgumentException! Fails with the following error: java.lang.IllegalArgumentException: Initial capacity must be greater than 0 at org.apache.commons.collections.map.AbstractHashedMap.<init> (AbstractHashedMap.java:142) at org.apache.commons.collections.map.AbstractHashedMap.<init> (AbstractHashedMap.java:127) at org.apache.commons.collections.map.AbstractLinkedMap.<init> (AbstractLinkedMap.java:95) at org.apache.commons.collections.map.LinkedMap.<init> (LinkedMap.java:78) at org.apache.commons.collections.map.TransformedMap.transformMap (TransformedMap.java:153) at org.apache.commons.collections.map.TransformedMap.putAll (TransformedMap.java:190) at net.carefx.contextagent.plugin.ldapuser.PluginTest.main (PluginTest.java:71) |
14 years, 7 weeks, 5 days ago | 18950 | No Perforce job exists for this issue. | 0 | 34686 | 164660 | 0|i0sjnb: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-122 | [collections] CircularFifoBuffer not really Serializable |
Bug | Closed | Major | Fixed | Unassigned | Kalle Gustafsson | Kalle Gustafsson | 27/Sep/04 14:24 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.1 | 3.2 | 0 | 0 | Operating System: Solaris Platform: Sun |
Create a CircularFifoBuffer of size N. Serialize and deserialize a couple of times. When adding element N+1, an error occurs. (OutOfMemoryError in our testing environment, ArrayIndexOutOfBounds when running the code snippet.) The error can be reproduced by running the following code snippet in a scrapbook page in WebSphere Studio 5.1.2 (default JRE) on Windows XP (The error occurs at the third add operation): org.apache.commons.collections.buffer.CircularFifoBuffer b = new org.apache.commons.collections.buffer.CircularFifoBuffer(2); b.add("a"); java.io.ByteArrayOutputStream bos = new java.io.ByteArrayOutputStream(); new java.io.ObjectOutputStream(bos).writeObject(b); org.apache.commons.collections.buffer.CircularFifoBuffer b2 = (org.apache.commons.collections.buffer.CircularFifoBuffer) new java.io.ObjectInputStream(new java.io.ByteArrayInputStream(bos.toByteArray())).readObject(); b2.add("b"); bos = new java.io.ByteArrayOutputStream(); new java.io.ObjectOutputStream(bos).writeObject(b2); b = (org.apache.commons.collections.buffer.CircularFifoBuffer) new java.io.ObjectInputStream(new java.io.ByteArrayInputStream(bos.toByteArray())).readObject(); b.add("c"); bos = new java.io.ByteArrayOutputStream(); new java.io.ObjectOutputStream(bos).writeObject(b); b2 = (org.apache.commons.collections.buffer.CircularFifoBuffer) new java.io.ObjectInputStream(new java.io.ByteArrayInputStream(bos.toByteArray())).readObject(); |
14 years, 19 weeks ago | 18876 | No Perforce job exists for this issue. | 0 | 31433 | 164586 | 0|i0sj6v: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-59 | [collections] FastArrayList iterator method throwing ConcurrentModificationException in 'fast' mode |
Bug | Closed | Major | Fixed | Unassigned | Robert Cooke | Robert Cooke | 17/Jun/04 06:55 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 3.2 | 0 | 0 | Operating System: Linux Platform: All |
Please review the below code, I was under the impression that this not throw an exception. Thanks, Rob Cooke. ---------------------------- import org.apache.commons.collections.FastArrayList; import java.util.Iterator; public class Test2 extends Thread{ public static void main(String argv[]) throws Exception{ FastArrayList array=new FastArrayList(); array.add("this"); array.add("is"); array.add("a"); new Test2(array).start(); array.setFast(true); Thread.sleep(2000); array.add("test"); } protected FastArrayList array; public Test2(FastArrayList array){ this.array=array; } public void run(){ for(Iterator i=array.iterator();i.hasNext();){ try{Thread.sleep(1000);}catch(Exception e){} System.out.println(i.next()); } } } |
15 years, 40 weeks, 5 days ago | 18939 | No Perforce job exists for this issue. | 0 | 29625 | 164649 | 0|i0sjkv: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-84 | TreeList with inproved iterator() and listIterator() implementation |
Bug | Closed | Major | Fixed | Unassigned | Joerg Schmuecker | Joerg Schmuecker | 12/May/04 23:08 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.1 | 0 | 0 | Operating System: other Platform: Other |
Added references to next and and prev using a flag. This is called Faedelung in German :-) |
15 years, 46 weeks, 5 days ago | 18914 | No Perforce job exists for this issue. | 2 | 28930 | 164624 | 0|i0sjfb: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-65 | [collections] Collection inside Abstract[AnyCollection]Decorator really needed to be transient? |
Bug | Closed | Major | Cannot Reproduce | Unassigned | Xavier Dury | Xavier Dury | 07/Sep/04 21:42 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: other Platform: Other |
Hi, I would like to know if there was any good reason for all abstract decorator classes (like AbstractMapDecorator) to have their decorated collection (map) transient? It doesn't help when trying to store decorated collections with XStream for example... Maybe there's a -really- good reason but I can't see it. thanks a lot and go on with the good work! :) Xavier. |
15 years, 29 weeks, 6 days ago | 18933 | No Perforce job exists for this issue. | 0 | 31091 | 164643 | 0|i0sjjj: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-26 | CompositeSet always supports remove operation |
Bug | Closed | Major | Fixed | Unassigned | Koji Sekiguchi | Koji Sekiguchi | 07/Sep/04 13:38 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: other Platform: Other |
CompositeSet javadoc says "If no strategy is provided then add and remove are unsupported." but the class always supports remove operation. The documentation should be revised as "If no strategy is provided then add is unsupported." regards, Koji |
15 years, 27 weeks, 5 days ago | 18972 | No Perforce job exists for this issue. | 0 | 31082 | 164682 | 0|i0sjs7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-37 | [collections] The commons-collections 'binary distro' on the Jakarta Website is actually the 'source distro' |
Bug | Closed | Major | Won't Fix | Unassigned | David Tonhofer | David Tonhofer | 23/Aug/04 23:22 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: Linux Platform: PC |
The subject says it all | 15 years, 32 weeks ago | 18961 | No Perforce job exists for this issue. | 0 | 30806 | 164671 | 0|i0sjpr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-39 | [collections] ExtendedProperties should not just allow NPEs |
Bug | Closed | Minor | Fixed | Unassigned | john tal | john tal | 06/Aug/04 01:23 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: other Platform: Other |
Its really an annoyance because I frequently have my debugger stop on NullPointerException. ExtendedProperties.readProperty Change from String line = readLine().trim(); to String line = readLine(); if(line != null) line = line.trim(); else return null; Also in ExtendedProperties.load while (true) { String line = reader.readProperty(); if(line == null) return; int equalSign = line.indexOf('='); |
15 years, 27 weeks, 5 days ago | 18959 | No Perforce job exists for this issue. | 0 | 30497 | 164669 | 0|i0sjpb: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-46 | [collections] CollectionUtils.transformedCollection(c,t) doesn't transform the elements of c |
Bug | Closed | Major | Won't Fix | Unassigned | Gunnar Zarncke | Gunnar Zarncke | 30/Jul/04 19:26 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.1 | 0 | 0 | Operating System: other Platform: All |
CollectionUtils.transformedCollection(c,t) doesn't transform the elements of c as documented in the API. The implementation passes this collection to TransformedCollection.decorate(collection, transformer) and further to new TransformedCollection(coll, transformer); where super(c) simply stored it WITHOUT conversion. |
15 years, 34 weeks, 6 days ago | 18952 | No Perforce job exists for this issue. | 1 | 30408 | 164662 | 0|i0sjnr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-587 | commons-collections-3.2.2 does not compile under docker fedora21 |
Bug | Resolved | Major | Won't Fix | Unassigned | Marc Pawlowsky | Marc Pawlowsky | 26/Apr/16 16:36 | 18/Mar/20 02:41 | 26/Apr/16 21:10 | 26/Apr/16 21:10 | 3.2 | 0 | 1 | docker, fedora21 | In a clean environment using docker, compile errors $cat Dockerfile FROM fedora:21 RUN yum update -y RUN yum install -y java-1.8.0-openjdk unzip maven wget RUN wget http://apache.mirror.rafal.ca//commons/collections/source/commons-collections-3.2.2-src.zip RUN unzip commons-collections-3.2.2-src.zip RUN cd commons-collections-3.2.2-src && mvn initialize RUN cd commons-collections-3.2.2-src && mvn install RUN chmod -R 755 /root CMD /bin/bash $docker build . <snip/> Downloaded: http://repo.maven.apache.org/maven2/commons-[INFO] Changes detected - recompiling the module! [INFO] Compiling 273 source files to /commons-collections-3.2.2-src/target/classes [INFO] ------------------------------------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiHashMap.java:[334,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.MultiHashMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map return type java.lang.Object is not compatible with boolean [ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiMap.java:[69,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.MultiMap clashes with remove(java.lang.Object,java.lang.Object) in java.util.Map return type java.lang.Object is not compatible with boolean [ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiValueMap.java:[156,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.map.MultiValueMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map return type java.lang.Object is not compatible with boolean [ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiKeyMap.java:[200,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.map.MultiKeyMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map return type java.lang.Object is not compatible with boolean [INFO] 4 errors [INFO] ------------------------------------------------------------- [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 19.104 s [INFO] Finished at: 2016-04-26T12:35:24-04:00 [INFO] Final Memory: 19M/203M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile) on project commons-collections: Compilation failure: Compilation failure: [ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiHashMap.java:[334,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.MultiHashMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map [ERROR] return type java.lang.Object is not compatible with boolean [ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiMap.java:[69,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.MultiMap clashes with remove(java.lang.Object,java.lang.Object) in java.util.Map [ERROR] return type java.lang.Object is not compatible with boolean [ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiValueMap.java:[156,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.map.MultiValueMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map [ERROR] return type java.lang.Object is not compatible with boolean [ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiKeyMap.java:[200,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.map.MultiKeyMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map [ERROR] return type java.lang.Object is not compatible with boolean [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException The command '/bin/sh -c cd commons-collections-3.2.2-src && mvn install' returned a non-zero code: 1 |
3 years, 47 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i2wrdr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-359 | A ∩ B != B ∩ A when duplicates are present in a list |
Bug | Closed | Major | Fixed | Unassigned | Mark Shead | Mark Shead | 05/Jul/10 14:58 | 09/Nov/14 14:31 | 28/Feb/13 19:37 | 3.2 | 4.0-alpha1, 4.0 | Collection | 0 | 1 | When duplicates are present in a list, ListUtils.intersection doesn't behave as expected. The intersection of two lists should give the same result regardless of which list comes first. ListUtils.intersection(A,B) should equal ListUtils.intersection(B,A). This is not the case when the list contains duplicates. Right now: [a, b] ∩ [a, a, b, b] = [a, a, b, b] and [a, a, b, b] ∩ [a, b] = [a, b] Expected behavior: [a, a, b, b] ∩ [a, b] = [a, b] [a, b] ∩ [a, a, b, b] = [a, b] Code demonstrating the problem. List A = new ArrayList(); List B = new ArrayList(); A.add("a"); A.add("b"); B.add("a"); B.add("a"); B.add("b"); B.add("b"); System.out.println("List A: " + A); System.out.println("List B: " + B); System.out.println("A ∩ B = " + ListUtils.intersection(A,B)); System.out.println("B ∩ A = " +ListUtils.intersection(B,A)); output: List A: [a, b] List B: [a, a, b, b] A ∩ B = [a, a, b, b] B ∩ A = [a, b] |
9 years, 36 weeks, 2 days ago | 18644 | No Perforce job exists for this issue. | 1 | 164388 | 0|i0shyv: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-360 | FilterListIterator#hasNext throws exception (associate with JUnit tests) |
Bug | Closed | Major | Fixed | Jochen Wiedmann | Sai Zhang | Sai Zhang | 23/Aug/10 19:29 | 09/Nov/14 14:31 | 01/Mar/11 22:17 | 3.2 | 4.0-alpha1, 4.0 | 0 | 1 | ubuntu | Hi, I found the some of the iterator classes does not fulfill the iterator specification of JDK. e.g. hasNext() should never throw exception. Here is an automatically generated junit test (I am now writing a tool) {code:java} public void test233() throws Throwable { java.lang.Integer var6 = new java.lang.Integer(0); org.apache.commons.collections.list.GrowthList var7 = new org.apache.commons.collections.list.GrowthList(var6); org.apache.commons.collections.Predicate var9 = org.apache.commons.collections.PredicateUtils.anyPredicate((java.util.Collection)var7); java.lang.Long var10 = new java.lang.Long(10L); org.apache.commons.collections.iterators.FilterListIterator var13 = new org.apache.commons.collections.iterators.FilterListIterator(var9); //this line throws exception! var13.hasNext(); } {code} could you please check it to confirm whether it is bug or I misunderstand the specification of apache common collections? thanks, |
9 years, 4 weeks ago | 18643 | No Perforce job exists for this issue. | 1 | 164387 | 0|i0shyn: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-357 | CollectionUtils.removeAll invokes wrong Listutils method |
Bug | Closed | Critical | Duplicate | Unassigned | Fabian Lange | Fabian Lange | 24/Jun/10 20:03 | 09/Nov/14 14:31 | 28/Feb/13 19:25 | 3.2 | 4.0-alpha1, 4.0 | Collection | 0 | 0 | COLLECTIONS-371, COLLECTIONS-386, COLLECTIONS-219, COLLECTIONS-358, COLLECTIONS-369, COLLECTIONS-376 | {code} public static Collection removeAll(Collection collection, Collection remove) { return ListUtils.retainAll(collection, remove); } {code} |
9 years, 36 weeks, 2 days ago | 18646 | No Perforce job exists for this issue. | 0 | 164390 | 0|i0shzb: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-331 | CollatingIterator NPE when Comparator is null |
Bug | Closed | Minor | Fixed | Jochen Wiedmann | Michael Krkoska | Michael Krkoska | 24/Jun/09 14:32 | 09/Nov/14 14:31 | 08/Mar/11 22:33 | 3.2 | 4.0-alpha1, 4.0 | Iterator | 0 | 1 | 300 | 300 | 0% | Run the attached Test against commons-collections-3.2.1. While the JavaDoc for CollatingIterator claims {{@param comp the comparator to use to sort, or null to use natural sort order}} the test fails, because the comparator is null. Fixing this requires a change in {{org.apache.commons.collections.iterators.CollatingIterator.least()}}: {code} if (comparator.compare(curObject,leastObject) < 0) { ... {code} could be replaced with {code} int c = comparator==null?((Comparable)curObject).compareTo(leastObject):comparator.compare(curObject,leastObject); if (c < 0) { ... {code} The workaround is to provide a comparator, of course. |
0% | 0% | 300 | 300 | 7 years, 34 weeks, 5 days ago | 18672 | No Perforce job exists for this issue. | 2 | 164410 | 0|i0si3r: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-373 | Bug in class#ListOrderedSet with reproducible JUnit test |
Bug | Closed | Major | Invalid | Unassigned | Sai Zhang | Sai Zhang | 03/Apr/11 07:43 | 18/Mar/20 02:40 | 27/Nov/15 21:47 | 23/Jan/13 17:05 | 3.2 | 0 | 0 | jdk 1.6.x | Hi all: I am writing an automated bug finding tool, and using Apache Commons Collections as an experimental subject for evaluation. The tool creates executable JUnit tests as well as explanatory code comments. I attached one bug-revealing test as follows. Could you please kindly check it, to see if it is a real bug or not? Also, it would be tremendous helpful if you could give some feedback and suggestion on the generated code comments? From the perspective of developers who are relatively familiar with the code, is the automatically-inferred comment useful in understanding the generated test? is the comment helpful in bug fixing? Your suggestion will help us improve the tool. Please see attachment for the failed test. A little explaination on the generated code comments in the failed test //explaination: //Test passes if var53 is: (java.lang.Boolean)false ===> means: // test passes if var52 is not added to var28 (only in that case, var53 is false) boolean var53 = var28.add((java.lang.Object)var52); |
patch | 7 years, 8 weeks, 6 days ago | 18630 | No Perforce job exists for this issue. | 1 | 90355 | 0|i0ftd3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-374 | Bug in class#BeanMap and TransformedBuffer with reproducible JUnit test |
Bug | Closed | Major | Won't Fix | Unassigned | Sai Zhang | Sai Zhang | 03/Apr/11 08:02 | 18/Mar/20 02:41 | 27/Nov/15 21:47 | 18/Apr/13 19:09 | 3.2 | 0 | 0 | jdk 1.6.0 | Hi all: (as in the previous post) I am writing an automated bug finding tool, and using Apache Commons Collections as an experimental subject for evaluation. The tool creates executable JUnit tests as well as explanatory code comments. I attached one bug-revealing test as follows. Could you please kindly check it, to see if it is a real bug or not? Also, it would be tremendous helpful if you could give some feedback and suggestion on the generated code comments? From the perspective of developers who are relatively familiar with the code, is the automatically-inferred comment useful in understanding the generated test? is the comment helpful in bug fixing? Your suggestion will help us improve the tool. Please see attachment for the failed test. The comment appears in the form of: //Tests pass if .... (it gives some small change to the test which can make the failed test pass) |
6 years, 48 weeks, 5 days ago | 18629 | No Perforce job exists for this issue. | 1 | 90354 | 0|i0ftcv: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-355 | class cast exception in common collection-3.2 jar |
Bug | Closed | Major | Invalid | Unassigned | maneesh | maneesh | 26/May/10 13:18 | 19/Jun/10 19:37 | 19/Jun/10 19:37 | 3.2 | Map | 0 | 0 | Unix, jdk 1.5.0.06 | Recently I have upgraded common collection jar to 3.2 version. After that I got a class cast exception in the following code java code String checkedInStation = (String)(((HashMap)lstQueuedPsgrs.get(startIndex)) .get("PSGRCHECKEDINSTATION")); The exception detail as below java.lang.ClassCastException: org.apache.commons.collections.map.ListOrderedMap at sun.reflect.GeneratedMethodAccessor279.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:287) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:181) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation |
9 years, 40 weeks, 3 days ago | 18648 | No Perforce job exists for this issue. | 0 | 164391 | 0|i0shzj: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-371 | BUG in org.apache.commons.collections.CollectionUtils.removeAll(Collection, Collection) |
Bug | Closed | Critical | Duplicate | Unassigned | li gui | li gui | 31/Jan/11 19:17 | 01/Feb/11 07:19 | 01/Feb/11 07:19 | 3.2 | Collection | 0 | 0 | COLLECTIONS-357 | line: 1121 public static Collection removeAll(Collection collection, Collection remove) { return ListUtils.retainAll(collection, remove); //<<<<<-------- here absolutely wrong! } |
9 years, 8 weeks, 1 day ago | 18632 | No Perforce job exists for this issue. | 0 | 164379 | 0|i0shwv: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-369 | CollectionUtils#removeAll is broken |
Bug | Closed | Major | Duplicate | Unassigned | Michael Harris | Michael Harris | 06/Jan/11 05:52 | 06/Jan/11 07:29 | 06/Jan/11 07:29 | 3.2 | 0 | 0 | COLLECTIONS-357 | method calls into ListUtils#retainAll instead of ListUtils#removeAll. Should be easy fix for someone with commit rights. | 9 years, 11 weeks, 5 days ago | 18634 | No Perforce job exists for this issue. | 0 | 164380 | 0|i0shx3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-363 | TransformedMap is Serializable but its superclass doesn't define an accessible void constructor |
Bug | Closed | Major | Fixed | Unassigned | Sebb | Sebb | 16/Oct/10 01:39 | 09/Nov/14 14:31 | 20/Dec/10 19:25 | 3.2 | 4.0-alpha1, 4.0 | Map | 0 | 1 | TransformedMap is Serializable but its superclass doesn't define an accessible void constructor. For example, the following test fails: {code} public void testSerialisation() throws Exception { TransformedMap<String, String, String, String> map = TransformedMap.decorate( new HashMap<String, String>(), NOPTransformer.<String> getInstance(), NOPTransformer.<String> getInstance()); ByteArrayOutputStream bytes = new ByteArrayOutputStream(); ObjectOutputStream out = new ObjectOutputStream(bytes); out.writeObject(map); // fails with java.io.InvalidClassException: org.apache.commons.collections.splitmap.TransformedMap; no valid constructor out.close(); } {code} |
9 years, 14 weeks, 1 day ago | 18640 | No Perforce job exists for this issue. | 4 | 164385 | 0|i0shy7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-377 | CollatingIterator throws NullPointerException when constructor is given null (or no) Comparator |
Bug | Closed | Minor | Duplicate | Unassigned | Ryan Hochstetler | Ryan Hochstetler | 18/Jul/11 19:51 | 18/Mar/20 02:41 | 09/Nov/14 14:31 | 03/Jun/12 11:19 | 3.2 | 4.0-alpha1, 4.0 | Iterator | 0 | 1 | Java 1.6.0_26 | CollatingIterator's javadoc (http://commons.apache.org/collections/api-release/index.html) states that natural sort ordering will be used when null is passed as the Comparator argument to any of the constructors accepting one (and for the nullary constructor). The following stack is thrown from the subsequent unit test. The implementation of least() does not appear to account for the natural sort order case. java.lang.NullPointerException at org.apache.commons.collections.iterators.CollatingIterator.least(CollatingIterator.java:334) at org.apache.commons.collections.iterators.CollatingIterator.next(CollatingIterator.java:230) at mil.af.statistics.jutl.collection.MutableDataSeriesTest... @SuppressWarnings("unchecked") @Test public void testCollatingIteratorNaturalOrdering() throws Exception { Integer[] expected = { Integer.valueOf(1), Integer.valueOf(2), Integer.valueOf(3), Integer.valueOf(4), Integer.valueOf(5), Integer.valueOf(6) }; List<Integer> evens = Arrays.asList(new Integer[] { Integer.valueOf(2), Integer.valueOf(4), Integer.valueOf(6) }); List<Integer> odds = Arrays.asList(new Integer[] { Integer.valueOf(1), Integer.valueOf(3), Integer.valueOf(5) }); Iterator<Integer> collatingIter = new CollatingIterator(null, evens.iterator(), odds.iterator()); for (Integer expectedInt : expected) { assertTrue(collatingIter.hasNext()); assertEquals(expectedInt, collatingIter.next()); } } Workaround: provide a Comparator that implements the natural ordering contract. |
7 years, 42 weeks, 2 days ago | 18626 | No Perforce job exists for this issue. | 0 | 164377 | 0|i0shwf: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-304 | SetUniqueList set method use corrupts uniqness |
Bug | Closed | Major | Fixed | Unassigned | Rafał Figas | Rafał Figas | 05/Sep/08 10:43 | 08/Nov/15 21:27 | 28/Feb/13 19:38 | 3.2 | 3.2.2, 4.0-alpha1, 4.0 | 0 | 0 | JDK 1.6/Windows/Eclipse Ganymede | When set method is used to put element (Strawberry) on list, then it is possible to add the same element (Strawberry) with add method. Also you cannot add element (Lemon) that has been once removed with set method. Reproduction code below: List<String> list = new LinkedList<String>(); SetUniqueList decoratedList = SetUniqueList.decorate(list); decoratedList.add("Apple"); decoratedList.add("Lemon"); decoratedList.add("Orange"); System.out.println(decoratedList.toString()); decoratedList.set(1, "Strawberry"); System.out.println(decoratedList.toString()); decoratedList.add(1, "Strawberry"); System.out.println(decoratedList.toString()); decoratedList.add(1, "Lemon"); System.out.println(decoratedList.toString()); |
11 years, 20 weeks, 6 days ago | 18697 | No Perforce job exists for this issue. | 2 | 164429 | 0|i0si7z: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-348 | Javadoc: incorrect behavior explained for XXXUtils.transformedXXX |
Bug | Closed | Major | Fixed | Unassigned | Paul Benedict | Paul Benedict | 20/Dec/09 03:58 | 09/Nov/14 14:31 | 15/Oct/10 19:39 | 3.2 | 4.0-alpha1, 4.0 | Bag, Collection, List, Map, Set | 0 | 0 | COLLECTIONS-288 | As a sequel to COLLECTIONS-288, any utility method that "transformed" needs to document that the incoming collection is not immediately transformed -- future additions are. Candidate methods: * BagUtils.transformedBag * BagUtils.transformedSortedBag * CollectionUtils.transform * CollectionUtils.transformedCollection * ListUtils.transformedList *done* * MapUtils.transformedMap * MapUtils.transformedSortedMap * SetUtils.transformedSet * SetUtils.transformedSortedSet |
9 years, 23 weeks, 4 days ago | 18655 | No Perforce job exists for this issue. | 0 | 164396 | 0|i0si0n: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-346 | SetUniqueList.decorate throws exceptions that is not documented |
Bug | Closed | Major | Won't Fix | Unassigned | Jimmy Shi | Jimmy Shi | 24/Nov/09 23:18 | 19/Jun/10 19:41 | 19/Jun/10 19:41 | 3.2 | List | 0 | 0 | public static void main(String[] args) { List<String> testList=Arrays.asList("a","b","c","a","b","c","e"); SetUniqueList decoratedList = SetUniqueList.decorate(testList); System.out.println(decoratedList); } throws below exception: Exception in thread "main" java.lang.UnsupportedOperationException at java.util.AbstractList.remove(AbstractList.java:172) at java.util.AbstractList$Itr.remove(AbstractList.java:437) at java.util.AbstractList.removeRange(AbstractList.java:662) at java.util.AbstractList.clear(AbstractList.java:258) at org.apache.commons.collections.list.SetUniqueList.decorate(SetUniqueList.java:80) caused by the list to decorate is unmodifiable. |
9 years, 40 weeks, 3 days ago | 18657 | No Perforce job exists for this issue. | 0 | 164397 | 0|i0si0v: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-310 | Modifications of a SetUniqueList.subList() invalidate the parent list |
Bug | Closed | Minor | Fixed | Unassigned | Christian Semrau | Christian Semrau | 10/Jan/09 13:58 | 18/Mar/20 03:00 | 09/Nov/14 14:31 | 27/Apr/13 11:57 | 3.2, Nightly Builds | 4.0-alpha1, 4.0 | List | 0 | 1 | COLLECTIONS-444 | The List returned by SetUniqueList.subList() is again a SetUniqueList. The contract for List.subList() says that the returned list supports all the operations of the parent list, and it is backed by the parent list. We have a SetUniqueList uniqueList equal to {"Hello", "World"}. We get a subList containing the last element. Now we add the element "Hello", contained in the uniqueList but not in the subList, to the subList. What should happen? Should the subList behave like a SetUniqueList and add the element - meaning that it changes position in the uniqueList because at the old place it gets removed, so now uniqueList equals {"World", "Hello"} (which fails)? Or should the element not be added, because it is already contained in the parent list, thereby violating the SetUniqueList-ness of the subList (which fails)? I prefer the former behaviour, because modifications should only be made through the subList and not through the parent list (as explained in List.subList()). What should happen if we replace (using set) the subList element "World" with "Hello" instead of adding an element? The subList should contain only "Hello", and for the parent list, the old element 0 (now a duplicate of the just set element 1) should be removed (which fails). And of course the parent list should know what happens to it (specifically, its uniqueness Set) (which fails in the current snapshot). public void testSubListAddNew() { List uniqueList = SetUniqueList.decorate(new ArrayList()); uniqueList.add("Hello"); uniqueList.add("World"); List subList = uniqueList.subList(1, 2); subList.add("Goodbye"); List expectedSubList = Arrays.asList(new Object[] { "World", "Goodbye" }); List expectedParentList = Arrays.asList(new Object[] { "Hello", "World", "Goodbye" }); assertEquals(expectedSubList, subList); assertEquals(expectedParentList, uniqueList); assertTrue(uniqueList.contains("Goodbye")); // fails } public void testSubListAddDuplicate() { List uniqueList = SetUniqueList.decorate(new ArrayList()); uniqueList.add("Hello"); uniqueList.add("World"); List subList = uniqueList.subList(1, 2); subList.add("Hello"); List expectedSubList = Arrays.asList(new Object[] { "World", "Hello" }); List expectedParentList = Arrays.asList(new Object[] { "World", "Hello" }); assertEquals(expectedSubList, subList); assertEquals(expectedParentList, uniqueList); // fails } public void testSubListSetDuplicate() { List uniqueList = SetUniqueList.decorate(new ArrayList()); uniqueList.add("Hello"); uniqueList.add("World"); List subList = uniqueList.subList(1, 2); subList.set(0, "Hello"); List expectedSubList = Arrays.asList(new Object[] { "Hello" }); List expectedParentList = Arrays.asList(new Object[] { "Hello" }); assertEquals(expectedSubList, subList); assertEquals(expectedParentList, uniqueList); // fails } |
6 years, 47 weeks, 3 days ago | 18691 | No Perforce job exists for this issue. | 5 | 90373 | 0|i0fth3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-308 | CollectionUtils.transform fails when collection is HashMap$Values |
Bug | Closed | Minor | Won't Fix | Unassigned | Lluís Martínez | Lluís Martínez | 23/Dec/08 23:32 | 24/Dec/08 14:19 | 24/Dec/08 14:19 | 3.2 | Collection | 0 | 0 | Ubuntu | I'm trying to apply a transformation to all values in a map : Collection values = map.values(); CollectionUtils.transform(values, transformer); Gives a java.lang.UnsupportedOperationException in CollectionUtils line 439. According to Javadoc the method values of Hashmap "does not support the add or addAll operations.". |
11 years, 13 weeks, 6 days ago | 18693 | No Perforce job exists for this issue. | 0 | 164426 | 0|i0si7b: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-376 | CollectionUtils.removeAll return retainAll - 3.2.1 |
Bug | Closed | Major | Duplicate | Unassigned | Patrick Sauts | Patrick Sauts | 01/Jul/11 17:15 | 18/Mar/20 02:41 | 01/Jul/11 23:03 | 01/Jul/11 23:03 | 3.2 | Collection | 0 | 0 | COLLECTIONS-357 | The code of removeAll method isn't correct ligne 1121 of CollectionUtils public static Collection removeAll(Collection collection, Collection remove) { return ListUtils.retainAll(collection, remove); } |
8 years, 38 weeks, 4 days ago | 18627 | No Perforce job exists for this issue. | 0 | 164378 | 0|i0shwn: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-294 | Fix case-insensitive string handling |
Bug | Closed | Major | Fixed | Unassigned | Benjamin Bentmann | Benjamin Bentmann | 25/Apr/08 14:31 | 07/Nov/15 21:17 | 28/Feb/13 19:38 | 3.2 | 3.2.2, 4.0-alpha1, 4.0 | Map | 0 | 0 | For example, the behavior of the {{CaseInsensitiveMap}} is currently platform-dependent, please see [Common Bug #3|http://www.nabble.com/Re%3A-Common-Bugs-p14931921s177.html] for details. | 11 years, 6 weeks, 1 day ago | 18707 | No Perforce job exists for this issue. | 2 | 164438 | 0|i0si9z: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-279 | LRUMap: moveToMRU is not invoked for new entry |
Bug | Closed | Blocker | Duplicate | Unassigned | Andrey Andreev | Andrey Andreev | 28/Nov/07 07:12 | 27/Nov/15 21:47 | 28/Feb/13 19:29 | 3.2 | Map | 2 | 1 | COLLECTIONS-262 | @Test public void testFirst() { LRUMap map = new LRUMap(); String key = "key1"; String value = "value1"; map.put(key, value); Assert.assertEquals(map.get(key), value); Assert.assertEquals(map.get(map.firstKey()), value); key = "key2"; value = "value2"; map.put(key, value); // here it fails Assert.assertEquals(map.get(map.firstKey()), value); } |
12 years, 2 weeks, 3 days ago | 18721 | No Perforce job exists for this issue. | 1 | 164449 | 0|i0sicf: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-278 | put() and putAll() don't update the getKeys() map |
Bug | Closed | Major | Fixed | Unassigned | Henning Schmiedehausen | Henning Schmiedehausen | 13/Nov/07 21:24 | 27/Nov/15 21:11 | 28/Feb/13 20:05 | 3.2 | 0 | 0 | COLLECTIONS-351 | If you use the put() or putAll() methods of the ExtendedProperties class, it will not update the contents of the internal keysAsListed map which in turn will return a different list of keys using the getKeys() method than the keySet() method does. The attached patchs fix this behaviour and add test cases. |
6 years, 48 weeks, 1 day ago | 18722 | No Perforce job exists for this issue. | 4 | 164450 | 0|i0sicn: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-271 | org.apache.commons.collections.ExtendedProperties#combine don't import string properly |
Bug | Closed | Major | Fixed | Unassigned | Alexander Borovsky | Alexander Borovsky | 16/Oct/07 12:40 | 27/Nov/15 21:11 | 28/Feb/13 19:56 | 3.2 | Collection | 1 | 1 | COLLECTIONS-351 | When we set property with escaped characters, after combine propertySets we got them unescaped. Simple Example ExtendedProperties props = new ExtendedProperties(); props.setProperty("test", "\\\\\\\\192.168.1.91\\\\test"); props.getProperty("test"); // => \\192.168.1.91\test ExtendedProperties props2 = new ExtendedProperties(); props2.combine(props); props.getProperty("test"); // => \192.168.1.91\test -- Wrong! |
6 years, 48 weeks, 1 day ago | 18729 | No Perforce job exists for this issue. | 3 | 164455 | 0|i0sidr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-284 | CollectionUtils.removeAll() calls ListUtils.retainAll() |
Bug | Closed | Major | Duplicate | Unassigned | Chuck Deal | Chuck Deal | 30/Jan/08 21:01 | 05/Feb/08 05:47 | 05/Feb/08 05:47 | 3.2 | 0 | 0 | COLLECTIONS-219 | CollectionUtils.removeAll() calls ListUtils.retainAll(). I believe it should actually be public static Collection removeAll(Collection collection, Collection remove) { return ListUtils.removeAll(collection, remove); } |
12 years, 8 weeks ago | 18716 | No Perforce job exists for this issue. | 0 | 164445 | 0|i0sibj: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-353 | AbstractLinkedMap firstKey/lastKey JavaDoc reversed |
Bug | Closed | Major | Duplicate | Unassigned | Michael Dürig | Michael Dürig | 23/Feb/10 10:15 | 27/Apr/13 21:26 | 19/Jun/10 19:28 | 3.2 | 4.0 | Map | 0 | 0 | COLLECTIONS-262 | According to the Javadoc on AbstractLinkedMap#firstKey and AbstractLinkedMap#lastKey the following test shouldn't fail: LinkedMap map = new LinkedMap(); map.put("one", "one"); map.put("two", "two"); assertEquals("one", map.lastKey()); assertEquals("two", map.firstKey()); |
9 years, 40 weeks, 3 days ago | 18650 | No Perforce job exists for this issue. | 0 | 164392 | 0|i0shzr: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-350 | MapUtils.getNumber sends output to System.out |
Bug | Closed | Minor | Fixed | Unassigned | Michael Akerman | Michael Akerman | 15/Jan/10 16:35 | 07/Nov/15 20:59 | 28/Feb/13 20:07 | 3.2 | 3.2.2, 4.0-alpha1, 4.0 | 0 | 0 | 3600 | 3600 | 0% | MapUtils.getNumber calls "logInfo" on a ParseException and it produces output on the System.out, instead of just returning "null" as the documentation states. Since the expected behavior is to return null, *not* print to System.out. I recommend we remove the call to logInfo and/or remove the System.out.println inside it. At minimum, if that's not agreed upon, the "side-effect" of writing to System.out should be documented. I'm happy to offer code for either of these fixes. |
0% | 0% | 3600 | 3600 | 10 years, 10 weeks, 4 days ago | 18653 | No Perforce job exists for this issue. | 0 | 164394 | 0|i0si07: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-349 | The method CollectionUtils.removeAll() call wrongly ListUtils.retainAll() |
Bug | Closed | Major | Duplicate | Unassigned | Mathieu | Mathieu | 07/Jan/10 10:47 | 27/Apr/13 21:26 | 19/Jun/10 19:21 | 3.2 | 4.0 | Collection | 0 | 0 | COLLECTIONS-219 | The method CollectionUtils.removeAll() calls wrongly ListUtils.retainAll() instead of ListUtils.removeAll(). | 9 years, 40 weeks, 3 days ago | 18654 | No Perforce job exists for this issue. | 0 | 164395 | 0|i0si0f: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-266 | Issue with MultiKey when serialized/deserialized via RMI |
Bug | Closed | Minor | Fixed | Unassigned | Julien Buret | Julien Buret | 11/Sep/07 21:02 | 07/Nov/15 20:54 | 28/Feb/13 19:57 | 3.2 | 3.2.2, 4.0-alpha1, 4.0 | KeyValue | 0 | 1 | COLLECTIONS-576 | This is because the hash code of MultiKey is calculated only once. So if the MultiKey is deserialized in an other jvm, and if one at least of the subkeys defines its hash code with System.identityHashCode() (for example all the enums does), then the hash code of the MultiKey is no longer valid, and you can't retreive the key in your Map. I fixed it by making the cached hash code field transient, and by recalculating the hash code during deserialization. |
11 years, 43 weeks, 4 days ago | 18734 | No Perforce job exists for this issue. | 7 | 164459 | 0|i0sien: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-262 | probably apidoc error: firstKey() and lastKey() in AbstractLinkedMap |
Bug | Closed | Major | Fixed | Unassigned | Lisen Mu | Lisen Mu | 29/Aug/07 04:10 | 09/Nov/14 14:31 | 28/Feb/13 19:28 | 3.2 | 4.0-alpha1, 4.0 | Map | 0 | 1 | COLLECTIONS-279, COLLECTIONS-353 | In the apidoc or source of org.apache.commons.collections.map.AbstractLinkedMap.firstKey(), it is said that this method "Gets the first key in the map, which is the most recently inserted.", which is exactly the actual behavior of lastKey(), and vice versa. So I think there is a typo with this class' javadoc. |
12 years, 12 weeks, 6 days ago | 18738 | No Perforce job exists for this issue. | 0 | 164462 | 0|i0sifb: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-261 | Flat3Map.remove() does not return the correct value when size <= 3 |
Bug | Closed | Major | Fixed | Unassigned | ori | ori | 18/Aug/07 14:12 | 08/Nov/15 21:04 | 20/Aug/07 14:11 | 3.2 | 3.2.2, 4.0 | Map | 0 | 0 | Windows XP, SUN JDK 1.5.0_06 | final Flat3Map m = new Flat3Map(); m.put( new Integer( 1 ), new Integer( 1 ) ); m.put( new Integer( 0 ), new Integer( 0 ) ); System.out.println( m.remove( new Integer( 1 ) ) ); The above code will print "0" when it should print "1" |
12 years, 32 weeks, 1 day ago | 18739 | No Perforce job exists for this issue. | 1 | 164463 | 0|i0sifj: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-265 | TreeBag allows uncomparable item to be added, breaking toString |
Bug | Closed | Minor | Fixed | Unassigned | David Saff | David Saff | 10/Sep/07 19:38 | 09/Nov/14 14:31 | 28/Feb/13 20:04 | 3.2 | 4.0-alpha1, 4.0 | Bag | 0 | 2 | The following code throws an exception not when the Object is added, but when toString is called: TreeBag bag = new TreeBag(); bag.add(new Object()); bag.toString(); Trace: java.lang.ClassCastException: java.lang.Object at java.util.TreeMap.compare(TreeMap.java:1093) at java.util.TreeMap.getEntry(TreeMap.java:347) at java.util.TreeMap.get(TreeMap.java:265) at org.apache.commons.collections.bag.AbstractMapBag.getCount(AbstractMapBag.java:116) at org.apache.commons.collections.bag.AbstractMapBag.toString(AbstractMapBag.java:581) [...] In a client program, toString should never throw an exception--it makes debugging much harder, for one thing. I believe that TreeBag should defend against the addition of uncomparable objects, so that toString will never throw an exception. |
12 years, 6 days ago | 18735 | No Perforce job exists for this issue. | 2 | 164460 | 0|i0siev: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-264 | FastTreeMap forgets the comparator |
Bug | Closed | Major | Fixed | Unassigned | Thomas Louis | Thomas Louis | 30/Aug/07 16:24 | 28/Feb/13 19:31 | 31/Aug/07 09:39 | 3.2 | Map | 0 | 0 | all | In line 359 and 582 of the current 3.2 release you should replace map = new TreeMap() with map = new TreeMap(map.comparator()); Otherwise the underlaying TreeMap looses ist comparator. |
12 years, 30 weeks, 4 days ago | 18736 | No Perforce job exists for this issue. | 0 | 164461 | 0|i0sif3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-323 | Behavior of constructors CaseInsensitiveMap inconsistent with standard Java HashMap |
Bug | Closed | Minor | Fixed | Jochen Wiedmann | Maarten Brak | Maarten Brak | 22/Apr/09 08:43 | 09/Nov/14 14:31 | 08/Mar/11 23:39 | 3.2 | 4.0-alpha1, 4.0 | Map | 0 | 2 | 86400 | 86400 | 0% | Any | The constructor CaseInsensitiveMap(int initialCapacity) throws an IllegalArgumentException if "the initial capacity is less than one". This is inconsistent with the standard Java HashMap constructor HashMap(int initialCapacity), which throws an if IllegalArgumentException if "the initial capacity is negative". Thus: new HashMap(0) ==> no exception new CaseInsensitiveMap(0) ==> IllegalArgumentException. This inconsistency is confusing. Actions: - Change Javadoc (this shouldn't be a problem in practice since surely there is no code around depending on the fact that the constructor throws an IllegalArgumentException :-)) - Change code. |
0% | 0% | 86400 | 86400 | 7 years, 34 weeks, 5 days ago | 18678 | No Perforce job exists for this issue. | 1 | 164415 | 0|i0si4v: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-307 | SetUniqueList.subList().contains() method checks against full parent list, not sublist range |
Bug | Closed | Minor | Fixed | Unassigned | Christian Semrau | Christian Semrau | 12/Nov/08 16:59 | 08/Nov/15 21:12 | 28/Feb/13 20:03 | 3.2 | 3.2.2, 4.0-alpha1, 4.0 | List | 0 | 0 | The view returned by the subList() method of a SetUniqueList checks contains() against the set of the original list. As shown by the following test snippet. List list = new ArrayList(); List uniqueList = SetUniqueList.decorate(list); uniqueList.add("Hello"); uniqueList.add("World"); List subList = list.subList(0, 0); List subUniqueList = uniqueList.subList(0, 0); assertFalse(subList.contains("World")); // passes assertFalse(subUniqueList.contains("World")); // fails |
11 years, 12 weeks, 1 day ago | 18694 | No Perforce job exists for this issue. | 1 | 164427 | 0|i0si7j: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-256 | ListUtils.transformedList(list, transformer) doesn't transform |
Bug | Closed | Major | Duplicate | Unassigned | Kurtis Williams | Kurtis Williams | 08/Jun/07 22:43 | 09/Nov/14 14:31 | 27/Apr/13 21:42 | 3.2 | 4.0-alpha1, 4.0 | List | 0 | 0 | COLLECTIONS-288 | Java 1.5 | The static method ListUtils.transformedList(List list, Transformer trans) does not apply the transformer before returning the list. I've traced into the code and it falls all the way through to the TransformedCollection constructor which has documentation that states that items existing in the list are NOT transformed. This yields bizarre unexpected behavior for this method. Conversely, the ListUtils.predicatedList(List list, Predicate pred) DOES apply the predicate. These methods are very similar but behave inconsistently. If the transformer is not applied to the list, the method's usefulness is somewhat limited and causes the user to create an extra unwanted list in some circumstances: // To transform an existing list List myList = ... some list to be transformed ... List transformed = ListUtils.transformedList(new ArrayList(), myTransformer); transformed.addAll(myList); I would expect a much shorter implementation such as: List transformed = ListUtils.transformedList(myList, myTransformer) |
12 years, 29 weeks, 6 days ago | 18744 | No Perforce job exists for this issue. | 1 | 164467 | 0|i0sigf: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-257 | CollectionUtils.removeAll() calls ListUtils.retainAll() |
Bug | Closed | Major | Duplicate | Unassigned | Sami Kallio | Sami Kallio | 25/Jun/07 10:53 | 27/Apr/13 21:26 | 26/Jun/07 15:40 | 3.2 | 4.0 | Collection | 0 | 0 | /** * Returns a collection containing all the elements in <code>collection</code> * that are also in <code>retain</code>. The cardinality of an element <code>e</code> * in the returned collection is the same as the cardinality of <code>e</code> * in <code>collection</code> unless <code>retain</code> does not contain <code>e</code>, in which * case the cardinality is zero. This method is useful if you do not wish to modify * the collection <code>c</code> and thus cannot call <code>c.retainAll(retain);</code>. * * @param collection the collection whose contents are the target of the #retailAll operation * @param retain the collection containing the elements to be retained in the returned collection * @return a <code>Collection</code> containing all the elements of <code>collection</code> * that occur at least once in <code>retain</code>. * @throws NullPointerException if either parameter is null * @since Commons Collections 3.2 */ public static Collection retainAll(Collection collection, Collection retain) { return ListUtils.retainAll(collection, retain); } /** * Removes the elements in <code>remove</code> from <code>collection</code>. That is, this * method returns a collection containing all the elements in <code>c</code> * that are not in <code>remove</code>. The cardinality of an element <code>e</code> * in the returned collection is the same as the cardinality of <code>e</code> * in <code>collection</code> unless <code>remove</code> contains <code>e</code>, in which * case the cardinality is zero. This method is useful if you do not wish to modify * the collection <code>c</code> and thus cannot call <code>collection.removeAll(remove);</code>. * * @param collection the collection from which items are removed (in the returned collection) * @param remove the items to be removed from the returned <code>collection</code> * @return a <code>Collection</code> containing all the elements of <code>collection</code> except * any elements that also occur in <code>remove</code>. * @throws NullPointerException if either parameter is null * @since Commons Collections 3.2 */ public static Collection removeAll(Collection collection, Collection remove) { return ListUtils.retainAll(collection, remove); } I guess the later method shoud be: public static Collection removeAll(Collection collection, Collection remove) { return ListUtils.removeAll(collection, remove); } |
12 years, 40 weeks ago | 18743 | No Perforce job exists for this issue. | 0 | 164466 | 0|i0sig7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-315 | CollectionUtils.removeAll calls the wrong ListUtils method |
Bug | Closed | Major | Duplicate | Unassigned | Christopher | Christopher | 03/Feb/09 19:30 | 01/May/12 12:03 | 03/Feb/09 20:40 | 3.2 | Core | 0 | 0 | COLLECTIONS-219 | Using version 3.2.1 as downloaded from maven's public repository. CollectionUtils.removeAll should call ListUtils.removeAll instead of ListUtils.retainAll. Currently {{public static Collection removeAll(Collection collection, Collection remove) { return ListUtils.retainAll(collection, remove); }}} Suggested {{public static Collection removeAll(Collection collection, Collection remove) { return ListUtils.*removeAll*(collection, remove); }}} |
7 years, 47 weeks ago | 18686 | No Perforce job exists for this issue. | 0 | 164422 | 0|i0si6f: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-236 | CollectionUtils.filter filters the inverse of what it is documented to filter |
Bug | Closed | Major | Invalid | Unassigned | Lee Wexler | Lee Wexler | 21/Nov/06 14:12 | 22/Nov/06 16:26 | 22/Nov/06 16:26 | 3.2 | Collection | 0 | 1 | The documentation states that when the predicate returns *false* the item will be removed. The implementation removes those items that return true. |
13 years, 18 weeks, 6 days ago | 18763 | No Perforce job exists for this issue. | 0 | 164482 | 0|i0sijr: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-246 | LoopingListIterator behaves unexpected on next and previous mixed |
Bug | Closed | Blocker | Invalid | Unassigned | Frank Hefter | Frank Hefter | 20/Mar/07 09:07 | 28/Feb/13 19:52 | 26/Apr/08 15:17 | 3.2 | Iterator | 0 | 2 | COLLECTIONS-239 | JDK 1.4.2_12 Common Collections 3.2 |
Using ArrayList as the backing list. This combination at least returns unexpected results as you can see in the testcase below. I used this for a list navigator in a web frontend and had trouble with users. I suspect java.util.AbstrList$ListItr (role of "cursor" var seems to be wrong implemented ) to cause this problem. If so maybe we have to implement it in a different way. Testcase (it runs without hassle but the comments show whats wrong): ------------------------------------------- import java.util.ArrayList; import junit.framework.TestCase; import org.apache.commons.collections.iterators.LoopingListIterator; public class SelectionControllerTest extends TestCase { public void testSelectorForApache() { ArrayList al = new ArrayList(); al.add("0"); al.add("1"); al.add("2"); LoopingListIterator it = new LoopingListIterator(al); assertEquals("0", it.next()); // This is OK // here I am on "0" assertEquals("0", it.previous()); // Wrong ! This should be 2! // here I am on "0" too! This is wrong. assertEquals("2", it.previous()); assertEquals("1", it.previous()); assertEquals("0", it.previous()); assertEquals("2", it.previous()); // here I am on "2" assertEquals("2", it.next()); // Wrong ! This should be 0! // here I am on "2" too! This is wrong. assertEquals("0", it.next()); assertEquals("1", it.next()); // here I am on "1" assertEquals("1", it.previous()); // Wrong ! This should be 0! } } ------------------------------------------- Thanks for your help. |
11 years, 48 weeks, 3 days ago | 18753 | No Perforce job exists for this issue. | 3 | 164475 | 0|i0sii7: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-249 | SetUniqueList.addAll(int index, Collection coll) adds to end of list instead of at specified index |
Bug | Closed | Minor | Fixed | Unassigned | Joe Kelly | Joe Kelly | 20/Apr/07 19:10 | 07/Nov/15 20:26 | 28/Feb/13 20:05 | 3.2 | 3.2.2, 4.0-alpha1, 4.0 | List | 0 | 1 | When you call SetUniqueList.addAll(int index, Collection coll), it incorrectly adds the new elements to the end of the list instead of at the specified index. | 12 years, 10 weeks, 2 days ago | 18750 | No Perforce job exists for this issue. | 2 | 164473 | 0|i0sihr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-240 | MultiValueMap should implement Serializable |
Bug | Closed | Blocker | Fixed | Unassigned | Wouter de Vaal | Wouter de Vaal | 20/Jan/07 14:09 | 09/Nov/14 14:31 | 28/Feb/13 20:04 | 3.2 | 4.0-alpha1, 4.0 | Map | 11 | 6 | COCOON-2146, COCOON-2151 | Collection classes should be serializable as they are frequently used in model classes which need to be serializable, for example in a HttpSession object within a servlet container cluster. | 11 years, 44 weeks, 4 days ago | 18759 | No Perforce job exists for this issue. | 1 | 163862 | 0|i0seq7: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-239 | In LinkIterator hasPrevious() is not working properly for the first entry |
Bug | Closed | Major | Won't Fix | Unassigned | Michael Pavlov | Michael Pavlov | 17/Jan/07 09:26 | 27/Apr/13 21:25 | 26/Mar/08 05:36 | 3.2 | Iterator | 0 | 1 | COLLECTIONS-246 | Windows XP, jdk-1.5.0_02 | In hasPrevious() method of LinkIterator 'next' field is used, that is not correct - method returns 'true' for the first entry. 'last' field should be used insted. | 7 years, 34 weeks, 5 days ago | 18760 | No Perforce job exists for this issue. | 1 | 164480 | 0|i0sijb: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-237 | MultiValueMap: behavior of entrySet().iterator() is not the expected one |
Bug | Closed | Major | Fixed | Unassigned | Nils Kaiser | Nils Kaiser | 12/Dec/06 18:09 | 09/Nov/14 14:31 | 27/Apr/13 11:09 | 3.2 | 4.0-alpha1, 4.0 | Map | 1 | 0 | The entrySet() method of the MultiValueMap delegates the entrySet() call to the decorated map, which is HashMap by default. The default hashmap iterator is used, which causes the iterator to return one Map.Entry for every key. The value returned for the key is an ArrayList, and not the value of the entry which was put into the map. The expected behavior would be the iterator to return the whole set of entries in the map, which requires iteration over the different array lists contained in the decorated map. |
6 years, 47 weeks, 3 days ago | 18762 | No Perforce job exists for this issue. | 0 | 90387 | 0|i0ftk7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-228 | MultiValueMap put and putAll do not return the correct values |
Bug | Closed | Minor | Fixed | Stephen Colebourne | Stephen Colebourne | Stephen Colebourne | 28/Oct/06 12:14 | 07/Nov/15 20:47 | 28/Feb/13 20:25 | 3.2 | 3.2.2, 4.0-alpha1, 4.0 | Map | 0 | 0 | MultiValueMap put and putAll do not return the correct values. putAll(Object, Collection) should return true if the map is changed. But if the key is new then this behaviour fails. put(Object, Object) should return the added value if the map is changed. But if the key is new then this behaviour fails. This was hidden because the test case referred to MultiHashMap and not MultValueMap. |
13 years, 22 weeks, 3 days ago | 18771 | No Perforce job exists for this issue. | 0 | 164490 | 0|i0silj: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-221 | CompositeCollection, CompositeMap, CompositeSet should implement Serializable |
Bug | Closed | Minor | Fixed | Unassigned | Pal Denes | Pal Denes | 12/Aug/06 17:10 | 09/Nov/14 14:31 | 28/Feb/13 20:08 | 3.2 | 4.0-alpha1, 4.0 | Collection, Map, Set | 1 | 1 | These classes should implement Serializable as usually all generial collection classes do. (At least I cannot think of a reason why they shouldn't and currently their usage is quite limited, like in RMI or http-sessions.) | 11 years, 46 weeks ago | 18778 | No Perforce job exists for this issue. | 1 | 164494 | 0|i0simf: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-222 | CollectionUtils removeAll is actually retainAll |
Bug | Closed | Major | Duplicate | Unassigned | Tim Lenz | Tim Lenz | 18/Aug/06 17:43 | 18/Aug/06 19:01 | 18/Aug/06 19:01 | 3.2 | Collection | 0 | 0 | COLLECTIONS-219 | The removeAll(Collection collection, Collection remove) method calls ListUtils.retainAll(collection, remove) instead of ListUtils.removeAll(Collection collection, Collection remove) Should be an easy fix |
13 years, 32 weeks, 4 days ago | 18777 | No Perforce job exists for this issue. | 0 | 164493 | 0|i0sim7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-219 | The CollectionUtils.removeAll method calls the ListUtils.retainAll method instead of the ListUtils.removeAll method. |
Bug | Closed | Major | Fixed | Stephen Colebourne | Tom Leccese | Tom Leccese | 02/Aug/06 17:37 | 07/Nov/15 19:51 | 28/Feb/13 20:25 | 3.2 | 3.2.2, 4.0-alpha1, 4.0 | Core | 0 | 4 | COLLECTIONS-487, COLLECTIONS-357, COLLECTIONS-437, COLLECTIONS-222, COLLECTIONS-284, COLLECTIONS-315, COLLECTIONS-349, COLLECTIONS-435 | The CollectionUtils.removeAll method calls the ListUtils.retainAll method instead of the ListUtils.removeAll method. | 4 years, 19 weeks, 3 days ago | 18780 | No Perforce job exists for this issue. | 0 | 115442 | 0|i0k3uv: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-217 | Flat3Map.Entry.setValue() overwrites other Entry values |
Bug | Closed | Critical | Fixed | Stephen Colebourne | Matt Bishop | Matt Bishop | 18/Jul/06 17:42 | 08/Nov/15 20:21 | 18/Jul/06 22:02 | 3.2 | 3.2.2, 4.0 | Map | 1 | 0 | JDK 1.4, WinXP | Flat3Map's Entry objects will overwrite other Entry's values if Entry.setValue() is called on one. It should only overwrite the Entry at hand. I've looked at the source, and the case statement incorrectly falls through, rather than returning like it should: Flat3Map.java, lines 646-660: public Object setValue(Object value) { if (canRemove == false) { throw new IllegalStateException(AbstractHashedMap.SETVALUE_INVALID); } Object old = getValue(); switch (nextIndex) { case 3: parent.value3 = value; case 2: parent.value2 = value; case 1: parent.value1 = value; } return old; } With this code, if I set the value of the third item in the EntrySet, then all three values are set to the new value. |
13 years, 37 weeks ago | 18782 | No Perforce job exists for this issue. | 0 | 164497 | 0|i0sin3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-220 | Serialization/Deserialization doesn't work well with empty buffers. |
Bug | Closed | Minor | Fixed | Unassigned | Jose Luis Huertas | Jose Luis Huertas | 07/Aug/06 13:53 | 27/Nov/15 21:11 | 28/Feb/13 20:08 | 3.2 | Buffer | 1 | 1 | COLLECTIONS-432 | When I serialize the queue to disk an it has elements, all works ok, but when I serialize an empty queue I have some problems when I create a new object using the serialized file. When I deserialize the queue it has a 'buffer' with size 1 (with null content), 'tail' and 'head' fields are 0 (they are declared transient). So, when I try to add a new object to the queue, the sentence: Object[] tmp = new Object[((buffer.length - 1) * 2) + 1]; Is executed in the add() method to increase the buffer length, but the buffer remains with the same size! (buffer.length = 1 --> (1 - 1) * 2 + 1 = 1). So, the object is added and when the tail is going to be incremented, it is reset to 0!! private int increment(int index) { index++; if (index >= buffer.length) { index = 0; } return index; } So it is impossible to add new elements after an empty queue has been serialized / deserialized. I attach a simple TestCase where this is proved. The example works when you use XMLEncoder to serialize the buffer but doesn't work if you use ObjectOutputStream or XStream. |
6 years, 48 weeks, 1 day ago | 18779 | No Perforce job exists for this issue. | 3 | 164495 | 0|i0simn: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-214 | ExtendedProperties - field include should be non-static and private |
Bug | Closed | Major | Fixed | Stephen Colebourne | Sebb | Sebb | 18/Jun/06 18:54 | 27/Apr/13 21:32 | 18/Jul/06 22:44 | 3.2 | 0 | 0 | COLLECTIONS-351 | The field "include" in ExtendedProperties is currently static and protected, yet has instance get/set accessors. Given that there are accessors, it seems unnecessary for the field to be protected - it could be private. The field should also surely be non-static - or the accessors should be made static, if the field really is supposed to be shared among instances. |
6 years, 47 weeks, 3 days ago | 18785 | No Perforce job exists for this issue. | 0 | 164500 | 0|i0sinr: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-87 | [collections] Implement a TimeoutBuffer class |
Bug | Closed | Major | Won't Fix | Unassigned | James Carman | James Carman | 12/Nov/05 05:35 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.2 | 0 | 0 | Operating System: other Platform: Other |
Please implement a TimeoutBuffer wrapper class which blocks on read()/get() operations until a timeout expires. |
14 years, 18 weeks, 6 days ago | 18911 | No Perforce job exists for this issue. | 0 | 37472 | 164621 | 0|i0sjen: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-17 | [collections] Enhance BlockingBuffer to allow for a timeout value |
Bug | Closed | Major | Fixed | Unassigned | James Carman | James Carman | 23/Nov/05 22:00 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.2 | 0 | 0 | Operating System: other Platform: Other |
BlockingBuffer currently waits forever. Add the capability to specify a timeout value to BlockingBuffer. |
14 years, 18 weeks, 6 days ago | 18981 | No Perforce job exists for this issue. | 0 | 37607 | 164691 | 0|i0sju7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-29 | [collections] "Upload to m2 repo @ibiblio.org" |
Bug | Closed | Major | Invalid | Unassigned | David J. M. Karlsen | David J. M. Karlsen | 15/May/06 21:27 | 18/Jul/06 22:04 | 18/Jul/06 22:04 | 3.2 | 0 | 1 | Operating System: other Platform: Other |
Could somebody upload collections 3.2 to www.ibiblio.org/maven2 repo? | 13 years, 37 weeks ago | 18969 | No Perforce job exists for this issue. | 0 | 39584 | 164679 | 0|i0sjrj: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-116 | [collections] Getting rid of some javadoc warn messages (3.2-dev) |
Bug | Closed | Minor | Fixed | Unassigned | Olaf Krische | Olaf Krische | 04/Oct/04 06:07 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 3.2 | 3.2 | 0 | 0 | Operating System: other Platform: Other |
Salut. Just called javadoc to create the java documentation and wondered about some warnings, though everything seemed to be at the right place: Tag @link: can't find removeLRU(LinkEntry) in org.apache.commons.collections.map.LRUMap Tag @link: can't find moveToMRU(LinkEntry) in org.apache.commons.collections.map.LRUMap "LinkEntry" is a static class in AbstractLinkedMap, LRUMap derives from AbstractLinkedMap. Why javadoc does not know about "LinkEntry" then, while java itself does? The solution comes from the javadoc-API: "Nested classes must be specified as outer.inner, not simply inner, for all forms." (http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/javadoc.html#@see) That is the reason, why javadoc spews warnings, when {@link #removeLRU(LinkEntry)} is used. The correct code will look like this then: {@link #removeLRU(AbstractLinkedMap.LinkEntry)} Actually i have found this only in collections.map.LRUMap, its really a minor thing. But even Eclipse gave me the "wrong" code... Thanks for the collections, we use them intensily here :-) Ciao. |
15 years, 13 weeks ago | 18882 | No Perforce job exists for this issue. | 9 | 31519 | 164592 | 0|i0sj87: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-52 | [collections] Method that add a Object to a Collection if it was not null |
Bug | Closed | Major | Fixed | Unassigned | Rafael U. C. Afonso | Rafael U. C. Afonso | 10/Jul/04 08:52 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 3.2 | 0 | 0 | Operating System: other Platform: Other |
It would be a new static method to CollectionUtils class. It would retur boolean because add() method from Collection returns a boolean. It would had only a line: public static boolean addNotNull(Collection c, Object o) { return (o != null)? c.add(o): false; } Of course if c was null, it will throw a NullPointerException. Aparently it is possible use a PredicatedCollection with NotNullPredicate. But it will trhow a IllegalArgumentException if o was null. It is not interesting. |
15 years, 37 weeks, 2 days ago | 18946 | No Perforce job exists for this issue. | 0 | 30020 | 164656 | 0|i0sjmf: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-379 | Bugs In Javadoc Comment in the CollectionUtils class |
Bug | Closed | Major | Fixed | Unassigned | SHIN HWEI TAN | SHIN HWEI TAN | 22/Sep/11 02:45 | 18/Mar/20 02:41 | 09/Nov/14 14:31 | 26/Jul/12 21:19 | 3.2 | 4.0-alpha1, 4.0 | Collection | 0 | 2 | 1200 | 1200 | 0% | System independent | I came across the following bugs in the Javadoc comments in the method below in the CollectionUtils class: 1. {quote} /** * Selects all elements from input collection which match the given predicate * and adds them to outputCollection. * <p> * If the input collection or predicate is null, there is no change to the * output collection. * * @param inputCollection the collection to get the input from, may be null * @param predicate the predicate to use, may be null * @*param outputCollection the collection to output into, may not be null* */ public static void select(Collection inputCollection, Predicate predicate, Collection outputCollection) { {quote} _This method will execute normally when calling select((Collection)null, (Predicate)null, (Collection)null) but the comment clearly states that outputCollection may not be null_ 2. {quote} /** * Selects all elements from inputCollection which don't match the given predicate * and adds them to outputCollection. * <p> * If the input predicate is <code>null</code>, no elements are added to <code>outputCollection</code>. * * @param inputCollection the collection to get the input from, may be null * @param predicate the predicate to use, may be null * @*param outputCollection the collection to output into, may not be null* */ public static void selectRejected(Collection inputCollection, Predicate predicate, Collection outputCollection) { {quote} _This method will execute normally when calling selectRejected((Collection)null, (Predicate)null, (Collection)null) but the comment also clearly states that outputCollection may not be null_ 3. {quote} /** * Transforms all elements from the inputIterator with the given transformer * and adds them to the outputCollection. * <p> * If the input iterator or transformer is null, there is no change to the * output collection. * * @param inputIterator the iterator to get the input from, may be null * @param transformer the transformer to use, may be null * @*param outputCollection the collection to output into, may not be null* * @return the outputCollection with the transformed input added * @*throws NullPointerException if the output collection is null* */ public static Collection collect(Iterator inputIterator, final Transformer transformer, final Collection outputCollection) { {quote} _This method will execute normally when calling collect((Iterator)null, (Transformer)null, (Collection)null) but the comment clearly states that NullPointerException will be thrown when the outputCollection is null_ 4. {quote} /** * Transforms all elements from inputCollection with the given transformer * and adds them to the outputCollection. * <p> * If the input collection or transformer is null, there is no change to the * output collection. * * @param inputCollection the collection to get the input from, may be null * @param transformer the transformer to use, may be null * @*param outputCollection the collection to output into, may not be null* * @return the outputCollection with the transformed input added * @*throws NullPointerException if the output collection is null* */ public static Collection collect(Collection inputCollection, final Transformer transformer, final Collection outputCollection) { {quote} _This method will execute normally when calling collect((Collection)null, (Transformer)null, (Collection)null) but the comment clearly states that NullPointerException will be thrown when the outputCollection is null_ The bugs in the Javadoc comments above could be confusing to the users of the Common Collection library and they could be fixed easily by the developers.. There are a few ways to fix the: 1. Throwing the NullPointerException explicitly when the outputCollection is null. 2. Changing the Javadoc comments to include the case where all of the parameters are null. |
0% | 0% | 1200 | 1200 | test | 7 years, 34 weeks, 5 days ago | 3625 | No Perforce job exists for this issue. | 0 | 164375 | 0|i0shvz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-652 | An obvious bug in CollectionUtils |
Bug | Closed | Minor | Fixed | Unassigned | samray leung | samray leung | 12/Jul/17 08:49 | 02/Aug/17 16:50 | 02/Aug/17 16:50 | 3.2.1 | 3.2.2 | Collection | 0 | 1 | 600 | 600 | 0% | windows 7, jdk8. This bug is so obvious so I think it is nothing to do with environment | In CollectionUtils.java: Line number: 1121 /** * Removes the elements in <code>remove</code> from <code>collection</code>. That is, this * method returns a collection containing all the elements in <code>c</code> * that are not in <code>remove</code>. The cardinality of an element <code>e</code> * in the returned collection is the same as the cardinality of <code>e</code> * in <code>collection</code> unless <code>remove</code> contains <code>e</code>, in which * case the cardinality is zero. This method is useful if you do not wish to modify * the collection <code>c</code> and thus cannot call <code>collection.removeAll(remove);</code>. * * @param collection the collection from which items are removed (in the returned collection) * @param remove the items to be removed from the returned <code>collection</code> * @return a <code>Collection</code> containing all the elements of <code>collection</code> except * any elements that also occur in <code>remove</code>. * @throws NullPointerException if either parameter is null * @since Commons Collections 3.2 */ public static Collection removeAll(Collection collection, Collection remove) { return ListUtils.retainAll(collection, remove); } The method should call ListUtils.removeAll(Collection collection, Collection remove) instead of calling ListUtils.retailAll(collection,remove) |
0% | 0% | 600 | 600 | easyfix | 2 years, 32 weeks, 6 days ago | 9223372036854775807 | /** * Removes the elements in <code>remove</code> from <code>collection</code>. That is, this * method returns a collection containing all the elements in <code>c</code> * that are not in <code>remove</code>. The cardinality of an element <code>e</code> * in the returned collection is the same as the cardinality of <code>e</code> * in <code>collection</code> unless <code>remove</code> contains <code>e</code>, in which * case the cardinality is zero. This method is useful if you do not wish to modify * the collection <code>c</code> and thus cannot call <code>collection.removeAll(remove);</code>. * * @param collection the collection from which items are removed (in the returned collection) * @param remove the items to be removed from the returned <code>collection</code> * @return a <code>Collection</code> containing all the elements of <code>collection</code> except * any elements that also occur in <code>remove</code>. * @throws NullPointerException if either parameter is null * @since Commons Collections 3.2 */ |
No Perforce job exists for this issue. | 0 | 9223372036854775807 |
Patch, Important
|
0|i3hf0f: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-538 | ExtendedProperties causes AccessControlException when framework is called from a script |
Bug | Closed | Major | Fixed | Unassigned | Trejkaz | Trejkaz | 03/Dec/14 23:58 | 27/Nov/15 21:11 | 08/Nov/15 15:08 | 3.2.1 | 3.2.2 | Collection | 0 | 1 | Java security manager enabled | We're using Velocity 1.7, which depends upon Commons Collections 3.x series' ExtendedProperties class. ExtendedProperties has these constructors where it looks up the file separator using the least convenient means possible: {code} public ExtendedProperties() { this.fileSeparator = System.getProperty("file.separator"); // ... } {code} For us, this is all being called from untrusted code, so this fails with AccessControlException. I think that instead of using the system property here, it is customary to use the File.separator constant. If you absolutely _must_ use System.getProperty() to fetch this value, it should at least be done from a doPrivileged() block. Also I had a quick check of Commons Collections 4 to see if this issue had been fixed, but couldn't immediately see what happened to this class. If it did turn out to have been fixed in v4, maybe Velocity could be encouraged to update to v4, but I haven't seen any updates from them in 4 years, so it's probably not a good sign. |
4 years, 19 weeks, 2 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i231d3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-444 | SetUniqueList may become inconsistent |
Bug | Closed | Major | Fixed | Unassigned | Thomas Vahrst | Thomas Vahrst | 25/Feb/13 16:08 | 08/Nov/15 21:36 | 17/Apr/13 18:13 | 3.2.1 | 3.2.2, 4.0-alpha1, 4.0 | List | 0 | 2 | COLLECTIONS-310 | I found this bug during my work on issue COLLECTIONS-310 : When you 'set' an element to a position that contains this element, it is removed from the internal set. This leads to the situation that - invocing get() returns the element - invocing contains() returns false. Extending the existing test method for set: {code} public void testSet() { final SetUniqueList<E> lset = new SetUniqueList<E>(new ArrayList<E>(), new HashSet<E>()); // Duplicate element final E obj1 = (E) new Integer(1); final E obj2 = (E) new Integer(2); final E obj3 = (E) new Integer(3); lset.add(obj1); lset.add(obj2); lset.set(0, obj1); assertEquals(2, lset.size()); assertSame(obj1, lset.get(0)); assertSame(obj2, lset.get(1)); assertTrue(lset.contains(obj1)); // fails ! assertTrue(lset.contains(obj2)); {code} |
6 years, 48 weeks, 6 days ago | 314421 | No Perforce job exists for this issue. | 0 | 314766 | 0|i1i9av: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-407 | ListOrderedSet.removeAll() is slow |
Bug | Closed | Major | Fixed | Unassigned | Adrian Nistor | Adrian Nistor | 01/Jun/12 17:55 | 09/Nov/14 14:31 | 19/Jun/12 19:00 | 3.2.1 | 4.0-alpha1, 4.0 | 0 | 2 | COLLECTIONS-408, COLLECTIONS-409 | java 1.6.0_24 Ubuntu 11.10 |
Hi, I am encountering a performance problem in ListOrderedSet.removeAll(). It appears in version 3.2.1 and also in revision 1344775 (31 May 2012). I have attached a test that exposes this problem and a one-line patch that fixes it. On my machine, for this test, the patch provides a 317X speedup. To run the test, just do: $ java Test The output for the un-patched version is: Time is 3812 The output for the patched version is: Time is 12 As the patch shows, the problem is in ListOrderedSet.remove(Object object). The code for this method is: boolean result = collection.remove(object); setOrder.remove(object); return result; The patch changes it to : boolean result = collection.remove(object); if (result) setOrder.remove(object); return result; The "setOrder.remove(object)" is not necessary if "collection.remove(object)" did not find the object. This small change speeds up ListOrderedSet.ListOrderedSet.removeAll(Collection<?> coll) because ListOrderedSet.ListOrderedSet.removeAll(Collection<?> coll) iterates over all the elements in "coll" and calls ListOrderedSet.remove(Object object). So the un-patched code has quadratic complexity, while the patched code has linear complexity. Is this truly a bug, or am I missing something here? If so, can you please confirm if the patch is correct? Thanks, Adrian |
7 years, 40 weeks ago | 292951 | No Perforce job exists for this issue. | 2 | 164353 | 0|i0shr3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-406 | ListUtils.subtract is very slow |
Bug | Closed | Major | Fixed | Unassigned | Adrian Nistor | Adrian Nistor | 27/May/12 19:52 | 09/Nov/14 14:31 | 03/Jun/12 10:25 | 3.2.1 | 4.0-alpha1, 4.0 | 0 | 3 | java 1.6.0_24 Ubuntu 11.10 |
Hi, ListUtils.subtract is very slow when subtracting two large lists. The root cause of this problem is similar to the root cause of the previously fixed COLLECTIONS-328 in ListUtils, i.e., quadratic complexity instead of linear complexity. I am encountering this problem in version 3.2.1 and also in revision 1342815 (May 25th 2012). I have attached a test that exposes this problem and a simple patch. On my machine, for the attached test, this patch provides a 95X speedup. To run the test, just do: $ java Test Currently, the code for ListUtils.subtract is: final ArrayList<E> result = new ArrayList<E>(list1); for (E e : list2) { result.remove(e); } return result; which is quadratic, because result.remove(e) has linear complexity. The attached patch makes the remove() be constant complexity by removing from an org.apache.commons.collections.bag.HashBag. I use HashBag and not HashSet because ListUtils.subtract needs to respect the cardinality when there are repeated objects in the list. As mentioned in COLLECTIONS-328 discussion, for small lists, there is some overhead for creating the HashBag. This can be fixed with a threshold, but I did not implement it in my patch because the COLLECTIONS-328 patch does not implement it. Unlike the patch for COLLECTIONS-328, my patch does not choose the list to iterate over based on size, because of the cardinality requirement in subtract. This means the code could be made even faster if we could use something like a LinkedHashBag but neither Apache Collections nor standard Java libraries have such a class. Even so, this patch is still a lot faster than the original version. Is this truly a bug, or am I missing something here? If so, can you please confirm if the patch is correct? Thanks, Adrian |
7 years, 42 weeks, 2 days ago | 292952 | No Perforce job exists for this issue. | 2 | 164354 | 0|i0shrb: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-401 | Inconsistent Javadoc comment and code in removeAll(Collection<E>, Collection<?>) in org.apache.commons.collections.ListUtils |
Bug | Closed | Major | Not A Problem | Unassigned | SHIN HWEI TAN | SHIN HWEI TAN | 30/Mar/12 03:02 | 27/Nov/15 21:47 | 26/Jul/12 21:02 | 3.2.1 | Collection | 0 | 1 | 180 | 180 | 0% | The Javadoc comment below states that the method "throws NullPointerException if either parameter is null". /*...... * * @throws NullPointerException if either parameter is null */ public static <E> List<E> removeAll(Collection<E> collection, Collection<?> remove) { .. } However, when called with two null collections (i.e., "removeAll((Collection)null, (Collection)null)"), the method executes normally without throwing any exception. Suggested Fixes: 1. Add code "if (collection == null) throw NullPointerException();" at the beginning of the method body. or 2. Remove "@throws NullPointerException if either parameter is null" from the Javadoc. or 3. Change "@throws NullPointerException if either parameter is null" to "@throws NullPointerException if the first collection is null or (the first collection is non-empty and the second collection is null)". |
0% | 0% | 180 | 180 | javadoc | 7 years, 39 weeks, 6 days ago | 233875 | No Perforce job exists for this issue. | 0 | 164358 | 0|i0shs7: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-400 | Inconsistent Javadoc comment and code in addIgnoreNull(Collection<T>, T) in org.apache.commons.collections.CollectionUtils |
Bug | Closed | Major | Fixed | Unassigned | SHIN HWEI TAN | SHIN HWEI TAN | 30/Mar/12 02:59 | 09/Nov/14 14:31 | 09/Apr/12 17:27 | 3.2.1 | 4.0-alpha1, 4.0 | Collection | 0 | 0 | 180 | 180 | 0% | Platform independent | The Javadoc comment below states that the method "throws NullPointerException if the collection is null". /** ..... * @param collection the collection to add to, must not be null * @param object the object to add, if null it will not be added * @return true if the collection changed * @throws NullPointerException if the collection is null */ public static <T> boolean addIgnoreNull(Collection<T> collection, T object) { return (object != null && collection.add(object)); } However, when called with an null collection and a null object (i.e., "addIgnoreNull((Collection)null, null)"), the method executes normally without throwing any exception. Suggested Fixes: 1. Add code "if (collection == null) throw NullPointerException();" at the beginning of the method body. or 2. Remove "@throws NullPointerException if the collection is null" from the Javadoc. or 3. Change "@throws NullPointerException if the collection is null" to "@throws NullPointerException if the collection is null and the object is non-null)". |
0% | 0% | 180 | 180 | javadoc | 7 years, 50 weeks, 1 day ago | 233874 | No Perforce job exists for this issue. | 0 | 164359 | 0|i0shsf: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-402 | Inconsistent Javadoc comment and code in intersection(List list1,List list2)in org.apache.commons.collections.ListUtils |
Bug | Closed | Major | Invalid | Unassigned | SHIN HWEI TAN | SHIN HWEI TAN | 30/Mar/12 03:42 | 27/Nov/15 21:47 | 26/Jul/12 20:59 | 3.2.1 | Collection | 0 | 0 | 180 | 180 | 0% | Platform Independent | The Javadoc comment below states that the method "throws NullPointerException if either list is null". /*...... * * @throws NullPointerException if either list is null */ public static List intersection(final List list1, final List list2) .. } However, when called with a null list1 and an empty list2(i.e., "intersection((List)null, new ArrayList())"), the method executes normally without throwing any exception. Suggested Fixes: 1. Add code "if (list1 == null) throw NullPointerException();" at the beginning of the method body. or 2. Remove "@throws NullPointerException if either list is null" from the Javadoc. or 3. Change "@throws NullPointerException if either list is null" to "@throws NullPointerException if list2 is null or (the list2 is non-empty and the list1 is null)". |
0% | 0% | 180 | 180 | 7 years, 50 weeks, 1 day ago | 233877 | No Perforce job exists for this issue. | 0 | 164357 | 0|i0shrz: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-472 | wasted work in AbstractMapBag.containsAll() |
Bug | Closed | Major | Fixed | Unassigned | Adrian Nistor | Adrian Nistor | 03/Jun/13 22:59 | 09/Nov/14 14:31 | 09/Jun/13 18:35 | 3.2.1 | 4.0-alpha1, 4.0 | Bag | 0 | 1 | any | The problem appears in version 3.2.1 and in revision 1489197. I attached a one-line patch that fixes it. In method "AbstractMapBag.containsAll", the loop over "other.uniqueSet()" should return immediately after "result" becomes "false", because "result = result && contains;" can never become "true" again. All the iterations after "result" becomes "false" do not perform any useful work, at best they just set "result" again to "false". |
patch,, performance | 6 years, 41 weeks, 2 days ago | 331088 | No Perforce job exists for this issue. | 1 | 331421 | 0|i1l4an: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-453 | findBugs Warnings: several classes in package functors may expose their internal representation |
Bug | Closed | Major | Fixed | Unassigned | Thomas Neidhart | Thomas Neidhart | 27/Apr/13 12:23 | 09/Nov/14 14:31 | 05/May/13 16:16 | 3.2.1 | 4.0-alpha1, 4.0 | 0 | 0 | Several classes (e.g. SwitchTransformer) take in their constructor an array as input which is not copied/cloned. Thus its internal representation may be changed externally. The corresponding factory methods *do* copy the input arguments thus we have two choices: * move the copy from the factory methods to the ctors * make the ctors private to prevent their use |
6 years, 46 weeks, 2 days ago | 325382 | No Perforce job exists for this issue. | 0 | 325727 | 0|i1k4wv: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-454 | findBugs Warning: Flat3Map - 3 iterators which are "both an Iterator and a Map.Entry" |
Bug | Closed | Major | Fixed | Unassigned | Thomas Neidhart | Thomas Neidhart | 27/Apr/13 12:26 | 09/Nov/14 14:31 | 28/Apr/13 18:53 | 3.2.1 | 4.0-alpha1, 4.0 | 0 | 0 | The iterators should be rewritten as suggested by findbugs. | 6 years, 47 weeks, 2 days ago | 325383 | No Perforce job exists for this issue. | 1 | 325728 | 0|i1k4x3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-435 | CollectionUtils.removeAll() calls ListUtils.retainAll() |
Bug | Closed | Major | Duplicate | Unassigned | Mikolaj Rydzewski | Mikolaj Rydzewski | 14/Nov/12 10:13 | 14/Nov/12 10:26 | 14/Nov/12 10:26 | 3.2.1 | Collection | 0 | 1 | COLLECTIONS-219 | A snippet from CollectionUtils.java: {code:title=CollectionUtils.java} public static Collection removeAll(Collection collection, Collection remove) { return ListUtils.retainAll(collection, remove); } {code} It should call ListUtils.removeAll() instead. |
7 years, 18 weeks, 6 days ago | 257655 | No Perforce job exists for this issue. | 0 | 115439 | 0|i0k3u7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-425 | performance problem in ListOrderedMap.remove() |
Bug | Closed | Major | Fixed | Unassigned | Adrian Nistor | Adrian Nistor | 24/Jul/12 18:15 | 09/Nov/14 14:31 | 25/Jul/12 21:15 | 3.2.1 | 4.0-alpha1, 4.0 | 0 | 2 | java 1.6.0_24 Ubuntu 11.10 |
Hi, I am encountering a performance problem in ListOrderedMap.remove(). It appears in version 3.2.1 and also in revision 1365132. I attached a test that exposes this problem and a simple patch that fixes it. On my machine, for this test, the patch provides a 213X speedup. To run the test, just do: $ java Test The output for the un-patched version is: Time is 1497 The output for the patched version is: Time is 7 The patch changes the "ListOrderedMap.remove(Object key)" code from: {code:java|borderStyle=solid} Object result = getMap().remove(key); insertOrder.remove(key); {code} to: {code:java|borderStyle=solid} if (decorated().containsKey(key)) { result = decorated().remove(key); insertOrder.remove(key); } {code} If "decorated()" does not contain the key, there is no need to remove it. This change significantly speeds up the code by avoiding the call to "insertOrder.remove(key)", which is very expensive because "insertOrder" is an ArrayList, and removing from an ArrayList is a linear time operation. It may appear that the check "if (decorated().containsKey(key))" may slow down the code when "decorated()" contains the key, because it adds a new operation "decorated().containsKey(key)", without avoiding the calls to "getMap().remove(key)" and "insertOrder.remove(key)". I attached a test, TestWorstCase.java, that show that, even when removing only existing keys (i.e., "decorated().containsKey(key)" always returns "true"), the patched version takes almost the same time as the un-patched version. To run TestWorstCase, just do: $ java TestWorstCase The output for the un-patched version for TestWorstCase is: Time is 96 The output for the patched version for TestWorstCase is: Time is 97 The reason why the patch does not slow down the code, even for this worst case, is because "decorated().containsKey(key)" is a "containsKey()" on a HashMap (very fast, constant time operation), whereas "insertOrder.remove(key);" is a "remove()" on an ArrayList (very slow, linear time operation). So the time taken by "decorated().containsKey(key)" is negligible compared to the time taken by "insertOrder.remove(key);". In other words, most of the time is spent inside "insertOrder.remove(key)", and performing one additional fast operation cannot be noticed. Is this truly a bug? If so, can you please confirm if the patch is correct? Thanks, Adrian |
7 years, 34 weeks, 6 days ago | 292941 | No Perforce job exists for this issue. | 3 | 164343 | 0|i0shov: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-426 | performance problem in ListOrderedSet.retainAll() |
Bug | Closed | Major | Fixed | Unassigned | Adrian Nistor | Adrian Nistor | 24/Jul/12 22:04 | 27/Nov/15 21:11 | 27/Jan/15 15:06 | 3.2.1 | 4.0-alpha1, 4.0, 4.1 | 0 | 1 | java 1.6.0_24 Ubuntu 11.10 |
Hi, I am encountering a performance problem in ListOrderedSet.retainAll(). It appears in version 3.2.1 and also in revision 1365132. I attached a test that exposes this problem and a patch that fixes it. On my machine, for this test, the patch provides a 263X speedup. To run the test, just do: $ java Test The output for the un-patched version is: Time is 3682 The output for the patched version is: Time is 14 The problem is that the code for method "ListOrderedSet.retainAll(Collection<?> coll)" is: {code:java|borderStyle=solid} public boolean retainAll(Collection<?> coll) { boolean result = collection.retainAll(coll); .... } {code} because "collection.retainAll(coll)" has quadratic complexity if parameter "coll" is a List. Conceptually, the solution is to call "coll.retainAll(collection)" which has linear complexity (not quadratic), because "collection" is always a HashSet (we know this, because "collection" is an inherited field of ListOrderedSet, and thus cannot have another type). See the "java.util.AbstractCollection.retainAll()" code inlined below for why one call has quadratic complexity, and the other has linear complexity. Directly calling "coll.retainAll(collection)" would change the behavior of ListOrderedSet.retainAll(), which is why the patch seems a bit involved. In reality, the patch simulates the behavior of "coll.retainAll(collection)" (which is just the intersection of two collections). You can easily see this by looking at the patch and at the "java.util.AbstractCollection.retainAll()" code inlined below. "collection.retainAll(coll)" is "java.util.HashSet.retainAll()", which is "java.util.AbstractCollection.retainAll()", which has the code: {code:java|borderStyle=solid} public boolean retainAll(Collection<?> c) { boolean modified = false; Iterator<E> e = iterator(); while (e.hasNext()) { if (!c.contains(e.next())) { e.remove(); modified = true; } } return modified; } {code} Is this a bug, or am I misunderstanding the intended behavior? If so, can you please confirm if the patch is correct? Thanks, Adrian |
5 years, 8 weeks ago | 255280 | No Perforce job exists for this issue. | 2 | 84081 | 0|i0eqnr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-427 | performance problem in SetUniqueList.retainAll() |
Bug | Closed | Major | Fixed | Unassigned | Mert Guldur | Mert Guldur | 24/Jul/12 23:50 | 27/Nov/15 21:11 | 27/Jan/15 15:09 | 3.2.1 | 4.0-alpha1, 4.0, 4.1 | 0 | 2 | java 1.6.0_24 Ubuntu 11.10 |
I am encountering a performance problem in SetUniqueList.retainAll(). It appears in version 3.2.1 and also in revision 1365132. I attached a test that exposes this problem and a patch that fixes it. On my machine, for this test, the patch provides a 621X speedup. To run the test, just do: $ java Test The output for the un-patched version is: Time is 6215 The output for the patched version is: Time is 10 There are two problems here. First, "SetUniqueList.retainAll()" should have similar implementation with the current implementation of "ListOrderedSet.retainAll()", which is more optimized. Second, even "ListOrderedSet.retainAll()" has a performance problem, which was reported and explained in detail in COLLECTIONS-426. The attached patch has two parts. The first part (the first loop) is inspired from COLLECTIONS-426. The second part (everything after the first loop) is in fact the current implementation of "ListOrderedSet.retainAll()", with some minor changes to adapt it for the current code. Overall, the attached patch is very similar to the COLLECTIONS-426 patch. I will rehash some of the information from COLLECTIONS-426 (which describes "ListOrderedSet.retainAll()") for the current "SetUniqueList.retainAll()". The current code for "SetUniqueList.retainAll()" is: {code:java|borderStyle=solid} public boolean retainAll(Collection<?> coll) { boolean result = super.retainAll(coll); set.retainAll(coll); return result; } {code} where both "super.retainAll(coll)" and "set.retainAll(coll)" can have quadratic complexity, e.g., if "coll" is a List. Both these calls to "retainAll" are in fact calls to "java.util.AbstractCollection.retainAll()", which has the code: {code:java|borderStyle=solid} public boolean retainAll(Collection<?> c) { boolean modified = false; Iterator<E> e = iterator(); while (e.hasNext()) { if (!c.contains(e.next())) { e.remove(); modified = true; } } return modified; } {code} which iterates over "this" and calls "contains()" on "c". Mapping this code back to "SetUniqueList.retainAll()" means that the code iterates over "this" and "set" and calls "contains()" on "coll". If "coll" has slow "contains()" (e.g., if "coll" is a list), then "SetUniqueList.retainAll()" has quadratic complexity. The patch iterates over "coll" and calls "contains()" on "set", which we know is fast, because "set" is a Set. For a more detailed discussion of the patch and the problem, see the current implementation of "ListOrderedSet.retainAll()", the discussion for COLLECTIONS-426, and the patch for COLLECTIONS-426. Is this a bug, or am I misunderstanding the intended behavior? If so, can you please confirm if the patch is correct? |
5 years, 8 weeks ago | 255281 | No Perforce job exists for this issue. | 2 | 84082 | 0|i0eqnz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-424 | Surprising exception by CompositeSet in a situation where CompositeCollection works fine |
Bug | Closed | Major | Fixed | Unassigned | Michael Pradel | Michael Pradel | 23/Jul/12 09:07 | 09/Nov/14 14:31 | 17/Mar/13 10:03 | 3.2.1 | 4.0-alpha1, 4.0 | Set | 0 | 3 | All environments | We have a method that uses a CompositeCollection. Here's a simplified version of it: void m(CompositeCollection coll) { coll.addComposited(new TreeBag()); } It works fine when the argument is a CompositeCollection, but it throws an exception when the argument is a CompositeSet. E.g.: m(new CompositeCollection()); // OK m(new CompositeSet()); // IllegalArgumentException Although the exception is documented in CompositeSet, this behavior is very surprising. Is there a way to have m() accept CompositeCollections without running into this exception? The only solution that comes to my mind is to dynamically check the type of 'coll' in m(), but this is a rather nasty work-around. A better solution may be to make the genericity of CompositeCollection explicit by adding a type parameter: class CompositeCollection<T extends Collection> { void addComposited(T c) { /* .. */ } } class CompositeSet extends CompositeCollection<Set> { @Override void addComposited(Set c) { /* .. */ } } This way, users of CompositeCollection must choose the kind of collections that can be composed and will not encounter surprises, such as the above. |
7 years, 1 week, 2 days ago | 244856 | No Perforce job exists for this issue. | 2 | 32006 | 0|i05uav: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-423 | FastArrayList.toString() fails to check for reference to itself |
Bug | Closed | Major | Won't Fix | Unassigned | Michael Pradel | Michael Pradel | 23/Jul/12 09:05 | 27/Nov/15 21:47 | 26/Aug/12 21:06 | 3.2.1 | List | 0 | 1 | All environments | FastArrayList.toString() throws a StackOverflowError when the list contains itself, because toString() is called recursively. In contrast, ArrayList checks for this case and deals with it appropriately. E.g.: ArrayList l = new FastArrayList(); l.add(l); l.toString(); // StackOverflowError But: ArrayList l = new ArrayList(); l.add(l); l.toString(); // OK To be compatible with its superclass, FastArrayList should also consider this special case. |
7 years, 34 weeks, 6 days ago | 255282 | No Perforce job exists for this issue. | 0 | 84083 | 0|i0eqo7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-418 | ListUtils.retainAll() is very slow |
Bug | Closed | Major | Won't Fix | Unassigned | Adrian Nistor | Adrian Nistor | 29/Jun/12 22:16 | 27/Nov/15 21:47 | 26/Aug/12 21:32 | 3.2.1 | 0 | 2 | java 1.6.0_24 Ubuntu 11.10 |
Hi, I am encountering a performance problem in ListUtils.retainAll(). It appears in version 3.2.1 and also in revision 1355448. I attached a test that exposes this problem and a one-line patch that fixes it. On my machine, for this test, the patch provides a 238X speedup. To run the test, just do: $ java Test The output for the un-patched version is: Time is 5485 The output for the patched version is: Time is 23 As the patch shows, the problem is that "ListUtils.retainAll(Collection<E> collection, Collection<?> retain)" performs "retain.contains(obj)" for each element in "collection", which can be very expensive if "retain.contains(obj)" is expensive, e.g., when "retain" is a list. The one-line patch I attached puts the elements of "retain" in a HashSet (which has very fast "contains()"), if "retain" is not already a set: "if (!(retain instanceof java.util.Set<?>)) retain = new HashSet<Object>(retain);" Is this a bug, or am I misunderstanding the intended behavior? If so, can you please confirm that the patch is correct? Thanks, Adrian |
7 years, 30 weeks, 2 days ago | 255284 | No Perforce job exists for this issue. | 2 | 84085 | 0|i0eqon: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-417 | AbstractLinkedList.retainAll() is very slow |
Bug | Closed | Major | Fixed | Unassigned | Adrian Nistor | Adrian Nistor | 29/Jun/12 22:01 | 09/Nov/14 14:31 | 20/Sep/12 18:07 | 3.2.1 | 4.0-alpha1, 4.0 | 0 | 2 | java 1.6.0_24 Ubuntu 11.10 |
Hi, I am encountering a performance problem in AbstractLinkedList.retainAll(). It appears in version 3.2.1 and also in revision 1355448. I attached a test that exposes this problem and a one-line patch that fixes it. On my machine, for this test, the patch provides a 158X speedup. To run the test, just do: $ java Test The output for the un-patched version is: Time is 5531 The output for the patched version is: Time is 35 As the patch shows, the problem is that "AbstractLinkedList.retainAll(Collection<?> coll)" performs "coll.contains(it.next())" for each element in the AbstractLinkedList, which can be very expensive if "coll.contains()" is expensive, e.g., when "coll" is a list. The one-line patch I attached puts the elements of "coll" in a HashSet (which has very fast "contains()"), if "coll" is not already a set: "if (!(coll instanceof java.util.Set<?>)) coll = new java.util.HashSet<Object>(coll);" Is this a bug, or am I misunderstanding the intended behavior? If so, can you please confirm that the patch is correct? Thanks, Adrian |
7 years, 26 weeks, 5 days ago | 244858 | No Perforce job exists for this issue. | 3 | 32008 | 0|i05ubb: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-415 | AbstractLinkedList.removeAll() is very slow |
Bug | Closed | Major | Fixed | Unassigned | Adrian Nistor | Adrian Nistor | 29/Jun/12 21:02 | 09/Nov/14 14:31 | 20/Sep/12 18:08 | 3.2.1 | 4.0-alpha1, 4.0 | 0 | 2 | java 1.6.0_24 Ubuntu 11.10 |
Hi, I am encountering a performance problem in AbstractLinkedList.removeAll(). It appears in version 3.2.1 and also in revision 1355448. I attached a test that exposes this problem and a one-line patch that fixes it. On my machine, for this test, the patch provides a 226X speedup. To run the test, just do: $ java Test The output for the un-patched version is: Time is 5655 The output for the patched version is: Time is 25 As the patch shows, the problem is that "AbstractLinkedList.removeAll(Collection<?> coll)" performs "coll.contains(it.next())" for each element in the AbstractLinkedList, which can be very expensive if "coll.contains()" is expensive, e.g., when "coll" is a list. The one-line patch I attached puts the elements of "coll" in a HashSet (which has very fast "contains()"), if "coll" is not already a set: "if (!(coll instanceof java.util.Set<?>)) coll = new java.util.HashSet<Object>(coll);" Is this a bug, or am I misunderstanding the intended behavior? If so, can you please confirm that the patch is correct? Thanks, Adrian |
7 years, 26 weeks, 5 days ago | 244857 | No Perforce job exists for this issue. | 3 | 32007 | 0|i05ub3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-416 | ListUtils.removeAll() is very slow |
Bug | Closed | Major | Won't Fix | Unassigned | Adrian Nistor | Adrian Nistor | 29/Jun/12 21:09 | 27/Nov/15 21:47 | 25/Jul/12 21:40 | 3.2.1 | 0 | 1 | java 1.6.0_24 Ubuntu 11.10 |
Hi, I am encountering a performance problem in ListUtils.removeAll(). It appears in version 3.2.1 and also in revision 1355448. I attached a test that exposes this problem and a one-line patch that fixes it. On my machine, for this test, the patch provides a 217X speedup. To run the test, just do: $ java Test The output for the un-patched version is: Time is 5430 The output for the patched version is: Time is 25 As the patch shows, the problem is that "ListUtils.removeAll(Collection<E> collection, Collection<?> remove)" performs "remove.contains(obj)" for each element in "collection", which can be very expensive if "remove.contains(obj)" is expensive, e.g., when "remove" is a list. The one-line patch I attached puts the elements of "remove" in a HashSet (which has very fast "contains()"), if "remove" is not already a set: "if (!(remove instanceof java.util.Set<?>)) remove = new HashSet<Object>(remove);" Is this a bug, or am I misunderstanding the intended behavior? If so, can you please confirm that the patch is correct? Thanks, Adrian |
7 years, 34 weeks, 6 days ago | 292943 | No Perforce job exists for this issue. | 2 | 164345 | 0|i0shpb: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-413 | Performance problem in DualHashBidiMap |
Bug | Closed | Major | Fixed | Unassigned | Adrian Nistor | Adrian Nistor | 21/Jun/12 18:38 | 09/Nov/14 14:31 | 23/Jun/12 12:06 | 3.2.1 | 4.0-alpha1, 4.0 | 0 | 2 | java 1.6.0_24 Ubuntu 11.10 |
Hi, I am encountering a performance problem in DualHashBidiMap. It appears in version 3.2.1 and also in revision 1352574 (21 June 2012). I attached a test that exposes this problem and a patch that fixes it. On my machine, for this test, the patch provides a 173X speedup. To run the test, just do: $ java Test The output for the un-patched version is: Time is 5029 The output for the patched version is: Time is 29 The attached test shows that, for a "DualHashBidiMap bidi" object, the following operation is very slow: bidi.entrySet().removeAll(toRemove); DualHashBidiMap.entrySet() returns a "DualHashBidiMap.EntrySet" object, which inherits removeAll(Collection<?> coll) from "DualHashBidiMap.View". As the patch shows, the problem is that "DualHashBidiMap.View.removeAll(Collection<?> coll)" performs "coll.contains(it.next())" for each element in the View. "coll.contains(it.next())" can be very slow, e.g., if "coll" is a list. The patch avoids this cost by using remove(Object obj) (defined in "EntrySet<K, V>", "KeySet<K>", and "Values<V>"), which is fast because it uses only operations on sets. Is this a bug, or am I misunderstanding something? If so, can you please confirm that the patch is correct? Thanks, Adrian |
7 years, 39 weeks, 3 days ago | 292945 | No Perforce job exists for this issue. | 2 | 164347 | 0|i0shpr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-420 | CompositeCollection.containsAll() is very slow |
Bug | Closed | Major | Won't Fix | Unassigned | Adrian Nistor | Adrian Nistor | 30/Jun/12 01:05 | 27/Nov/15 21:47 | 26/Aug/12 21:25 | 3.2.1 | 0 | 2 | java 1.6.0_24 Ubuntu 11.10 |
Hi, I am encountering a performance problem in CompositeCollection.containsAll(). It appears in version 3.2.1 and also in revision 1355448. I attached a test that exposes this problem and a patch that fixes it. On my machine, for this test, the patch provides a 167X speedup. To run the test, just do: $ java Test The output for the un-patched version is: Time is 9192 The output for the patched version is: Time is 54 The problem is that "CompositeCollection.containsAll(Collection<?> coll)" performs "contains(item)" for each item in "coll", and "contains(item)" searches "item" in all collections in CompositeCollection. This can be very slow if the collections in CompositeCollection have slow "contains()", e.g., when these collections are lists. The patch I attached puts the elements in each collection of CompositeCollection in a HashSet (which has very fast "contains()") if that collection is not already a set. For efficiency, putting elements in several HashSet objects is performed lazily in the patch. Is this a bug, or am I misunderstanding the intended behavior? If so, can you please confirm that the patch is correct? Thanks, Adrian |
7 years, 30 weeks, 2 days ago | 255283 | No Perforce job exists for this issue. | 2 | 84084 | 0|i0eqof: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-409 | ListOrderedSet.addAll() is very slow |
Bug | Closed | Major | Fixed | Unassigned | Adrian Nistor | Adrian Nistor | 19/Jun/12 16:00 | 09/Nov/14 14:31 | 19/Jun/12 19:52 | 3.2.1 | 4.0-alpha1, 4.0 | 0 | 2 | COLLECTIONS-407 | java 1.6.0_24 Ubuntu 11.10 |
Hi, I am encountering a performance problem in ListOrderedSet.addAll(). It appears in version 3.2.1 and also in revision 1351465 (18 Jun 2012). I have attached a test that exposes this problem and a three-line patch that fixes it. On my machine, for this test, the patch provides a 79X speedup. To run the test, just do: $ java Test The output for the un-patched version is: Time is 1837 The output for the patched version is: Time is 23 As the patch shows, the problem is that ListOrderedSet.addAll(int index, Collection<? extends E> coll) performs: "setOrder.add(index++, e)" for each element in "coll". This is very expensive, because "setOrder" is an ArrayList, and inserting an element in the middle of an ArrayList shifts all the elements to the right. The patched version avoids this cost by inserting all the elements at once, thus performing only one insert. Is this a bug? If so, can you please confirm that the patch is correct? Thanks, Adrian |
7 years, 40 weeks ago | 292949 | No Perforce job exists for this issue. | 2 | 164351 | 0|i0shqn: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-524 | ListOrderedSet can have duplicates |
Bug | Closed | Major | Fixed | Unassigned | J Goodfellow | J Goodfellow | 06/May/14 00:58 | 27/Nov/15 21:11 | 06/May/14 22:14 | 3.2.1, 4.0 | 4.1 | 0 | 1 | tomcat 7, linux | The static method, org.apache.commons.collections.set.ListOrderedSet.decorate(List list), has a comment "If the list contains duplicates, the duplicates are removed". It does not remove duplicates and will leave you in an inconsistent state if your list has duplicates. (i.e. the .size() result is smaller than the number of iterations from the iterator) | 5 years, 46 weeks ago | 390786 | No Perforce job exists for this issue. | 0 | 391026 | 0|i1vb5z: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-487 | CollectionUtils.removeAll is not work as expected |
Bug | Closed | Blocker | Duplicate | Unassigned | Cooper | Cooper | 21/Oct/13 07:48 | 09/Nov/14 14:31 | 21/Oct/13 07:56 | 3.2.1 | 4.0 | Collection, List | 0 | 1 | 360 | 360 | 0% | COLLECTIONS-219 | JDK 1.6 | http://svn.apache.org/viewvc/commons/proper/collections/tags/COLLECTIONS_3_2_1/src/java/org/apache/commons/collections/CollectionUtils.java?revision=1211567&view=markup Line: 1122 Problem: The method called "removeAll", but call "retainAll" internally. |
0% | 0% | 360 | 360 | 6 years, 22 weeks, 1 day ago | 354363 | No Perforce job exists for this issue. | 0 | 354653 | 0|i1p3cf: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-536 | (Code style) map.size() call in MapUtils.putAll() |
Bug | Closed | Trivial | Fixed | Unassigned | Tagir Valeev | Tagir Valeev | 29/Oct/14 02:58 | 27/Nov/15 21:11 | 29/Oct/14 21:05 | 3.2.1, 4.0 | 4.1 | Map | 0 | 1 | Any | In class org.apache.commons.collections(4).MapUtils there's a method putAll(final Map<K, V> map, final Object[] array) which starts with {noformat} map.size(); // force NPE {noformat} Actually map.size() is not that harmless call for any map. For example, consider java.util.concurrent.ConcurrentHashMap size() implementation: depending on the circumstances it may take even more time than the rest of the putAll method (at least prior to JDK 8). Things are even worse for ConcurrentSkipListMap: its size() method iterates over all the map elements. Thus I'd suggest to replace this call with more conventional check like: {noformat} if(map == null) { throw new NullPointerException(); } {noformat} If you still want to save bytes, you may use {{map.getClass()}}. It's final, so it will never be overridden to do something strange and it's even used by JavaC for the same purpose (to trigger NPE). For example, if you compile and disassemble this code: {noformat} public class Outer { public class Inner {} public void test(Outer n) { n.new Inner(); } } {noformat} You will see a getClass() call which is used to trigger NPE. |
performance | 5 years, 20 weeks, 6 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i21pc7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-394 | FastTreeMap is not compatible with TreeMap |
Bug | Closed | Major | Won't Fix | Unassigned | Michael Pradel | Michael Pradel | 29/Feb/12 14:49 | 27/Nov/15 21:47 | 23/Jun/12 17:14 | 3.2.1 | Map | 0 | 1 | all | FastTreeMap extends TreeMap in a way that doesn't preserve the superclass behavior. For example, the following code prints 'null', but I would expect it to print '1=1', which is what TreeMap does: TreeMap map = new FastTreeMap(); //TreeMap map = new TreeMap(); map.put(1, "1"); map.put(3, "3"); Entry e = map.floorEntry(2); System.out.println(e); This behavior is surprising and can hit you every time a reference of type TreeMap refers to an instance of FastTreeMap. A subclass instance used through a superclass interface shouldn't change the visible behavior of its superclass. The reason for this problem seems to be that FastTreeMap both extends TreeMap and delegates to a TreeMap via the 'map' field. I.e., there are two map instances for a single FastTreeMap instance. |
7 years, 39 weeks, 3 days ago | 229815 | No Perforce job exists for this issue. | 0 | 164361 | 0|i0shsv: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-387 | CollectionUtils.removeAll does retain instead of remove |
Bug | Closed | Major | Duplicate | Unassigned | Taras Pushyk | Taras Pushyk | 27/Dec/11 12:34 | 28/Feb/13 20:02 | 27/Dec/11 12:35 | 3.2.1 | 4.0 | Collection | 0 | 0 | org.apache.commons.collections.CollectionUtils.removeAll(Collection, Collection) method calls org.apache.commons.collections.ListUtils.retainAll(Collection, Collection) instead of org.apache.commons.collections.ListUtils.removeAll(Collection, Collection). | bug, removeAll | 8 years, 13 weeks ago | 222100 | No Perforce job exists for this issue. | 0 | 164368 | 0|i0shuf: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-386 | CollectionUtils.removeAll(Collection, Collection) has an CopyPaste-Failure |
Bug | Closed | Critical | Duplicate | Joerg Schaible | Steininger Thomas | Steininger Thomas | 03/Nov/11 14:07 | 03/Nov/11 16:19 | 03/Nov/11 16:19 | 3.2.1 | 4.0, Nightly Builds | 0 | 1 | COLLECTIONS-357 | commons-collections-3.2.1.jar | public static Collection removeAll(Collection collection, Collection remove) { return ListUtils.retainAll(collection, remove); } |
8 years, 20 weeks, 5 days ago | 215909 | No Perforce job exists for this issue. | 0 | 164369 | 0|i0shun: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-690 | Source code compilation error |
Bug | Resolved | Major | Won't Fix | Unassigned | Jayanth G H | Jayanth G H | 20/Jul/18 05:13 | 18/Mar/20 02:55 | 20/Jul/18 08:56 | 20/Jul/18 08:56 | 3.2.2 | Collection | 0 | 1 | Windows 10
JDK 1.8 |
# Took source code from "https://github.com/apache/commons-collections/tree/collections-3.2.2"
# Trying to compile the code using "ant compile" in command prompt # Got the compilation error. Error logs is attached. |
1 year, 34 weeks, 4 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 1 | 9223372036854775807 |
Important
|
0|i3w3lj: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-712 | ExtendedProperties.save swallows instead of throws IOException |
Bug | Closed | Trivial | Won't Fix | Unassigned | Philip Hodges | Philip Hodges | 18/Mar/19 13:39 | 05/Jul/19 17:23 | 05/Jul/19 15:31 | 3.2.2 | Properties | 0 | 1 | commons-collections-3.2.2-src/src/java/org/apache/commons/collections/ExtendedProperties.java
/** * Save the properties to the given output stream. * ... * @throws IOException if an IO error occurs - no it does not. */ public synchronized void save(OutputStream output, String header) throws IOException { ... PrintWriter theWrtr = new PrintWriter(output); ... // theWrter.flush(); // missing: if (theWrtr.checkError()) throw new IOException(); Impact: caller cannot tell if the properties were completely saved, perhaps the disk filled up instead. Missing checkError is an antipattern for PrintWriter and PrintStream. |
36 weeks, 4 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|z00tgo: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-701 | StackOverflowError in SetUniqueList.add() when it receives itself |
Bug | Resolved | Critical | Fixed | Unassigned | Shin Hong | Shin Hong | 31/Oct/18 12:38 | 23/Nov/18 07:32 | 23/Nov/18 07:32 | 3.2.2 | 4.3 | Collection | 0 | 5 | Hi.
We found that the following test case fails with a StackOverFlowError exception: {code:java} test() { SetUniqueList l = new SetUniqueList(new LinkedList<Object>()) ; l.add((Object) l) ; }{code} The add() execution traps into an infinite recursion which crashes the program. From the stack trace, we found that the infinite recursion occurs at AbstractList.hashCode() since it invokes hashCode() of each of its elements. |
1 year, 16 weeks, 4 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 |
Important
|
0|i3zucv: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-596 | FileInputStream is not closed |
Bug | Resolved | Major | Won't Fix | Unassigned | Kaloyan Spiridonov | Kaloyan Spiridonov | 30/Sep/16 13:36 | 24/May/17 08:34 | 24/May/17 08:34 | 3.2.2 | 0 | 2 | In ExtendedProperties class on 602 line the function load is called with input stream. I do not see anywhere stream to be closed. Is there any reason for that? | 2 years, 42 weeks, 6 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i34avr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-585 | When use commons collection 3.2.2, show "JavaSE not found" |
Bug | Open | Minor | Unresolved | Unassigned | neal zhang11 | neal zhang11 | 29/Jan/16 02:53 | 18/Mar/20 02:08 | 04/Nov/19 03:07 | 3.2.2 | Collection | 0 | 3 | jdk1.7 commons-collections 3.2.2 | Hi all, when i use commons-collections 3.2.2, and build my rcp application. it always show this error: [java] [eclipse.generateFeature] Some inter-plug-in dependencies have not been satisfied. [java] [eclipse.generateFeature] Bundle org.apache.commons.collections: [java] [eclipse.generateFeature] Host plug-in JavaSE_0.0.0 has not been found. but for commons-collections 3.2.1.every thing is fine. and compared the 3.2.2 and 3.2.1 Mainfest.mf file add this: Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.3))" if remove it, i can build my application. i use jdk1.7 in my local(i also tested jdk1.8, same problem) so i don't understand why show this problem. i am new guy for this, if misunderstand this, sorry |
19 weeks, 1 day ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i2s4lr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-582 | Maven repository metadata of Commons Collections in bad condition |
Bug | Closed | Major | Won't Fix | Unassigned | Alexander Veit | Alexander Veit | 18/Nov/15 08:00 | 27/Nov/15 21:47 | 18/Nov/15 08:05 | 3.2.2 | Core | 0 | 2 | The metadata located at https://repo1.maven.org/maven2/commons-collections/commons-collections/maven-metadata.xml are in a bad condition. It states that latest version and release version is 20040616. Moreover, the list of versions does not reflect the actual release order. This makes it difficult to automatically check for new versions in our QA processes. |
4 years, 17 weeks, 6 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i2okcf: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-482 | Transformed* classes require double the number of generic qualifiers |
Bug | Closed | Major | Duplicate | Unassigned | Hollis Waite | Hollis Waite | 10/Sep/13 18:16 | 18/Mar/20 02:58 | 27/Nov/15 21:47 | 10/Sep/13 19:55 | 4.0-alpha1 | Bag, Collection, List, Map, Set | 0 | 1 | COLLECTIONS-333 | Transformed* classes currently have the same number of generic qualifiers as their parent interfaces (e.g. one for TransformedList and two for TransformedMap). In order to handle transformations between different types, transforming collections should specify both input and output classes. | 6 years, 28 weeks ago | 347799 | No Perforce job exists for this issue. | 0 | 348098 | 0|i1nz13: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-475 | Wrong timeout handling in expiration policies of PassiveExpiringMap |
Bug | Closed | Minor | Fixed | Unassigned | Thomas Neidhart | Thomas Neidhart | 02/Jul/13 21:04 | 09/Nov/14 14:31 | 14/Jul/13 19:09 | 4.0-alpha1 | 4.0 | 0 | 0 | The timeunit parameter in the ctor of ConstantTimeToLiveExpirationPolicy is not used. Additionally, the validateAndConvertToMillis method is wrong, it should be changed like this: {noformat} private static long validateAndConvertToMillis(final long timeToLive, final TimeUnit timeUnit) { if (timeUnit == null) { throw new IllegalArgumentException("Time unit must not be null"); } return TimeUnit.MILLISECONDS.convert(timeToLive, timeUnit); } {noformat} |
6 years, 36 weeks, 2 days ago | 336120 | No Perforce job exists for this issue. | 0 | 336444 | 0|i1lz7z: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-498 | CollectionBag should respect removeAll / retainAll contract of decorated bags |
Bug | Closed | Major | Fixed | Unassigned | Thomas Neidhart | Thomas Neidhart | 11/Nov/13 19:46 | 09/Nov/14 14:31 | 11/Nov/13 20:29 | 4.0-alpha1 | 4.0 | 0 | 0 | In case the decorated collection does not support removal, i.e. throws an UnsupportedOperationException, CollectionBag does not respect this in case a null argument was specified. To be consistent with the testing framework, CollectionBag shall delegate the call to the decorated collection in such cases. |
6 years, 19 weeks, 1 day ago | 358017 | No Perforce job exists for this issue. | 0 | 358307 | 0|i1ppuv: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-501 | Rename MultiKeyMap.remove(K key1, K key2) to avoid clashes with newly introduced default methods in Java 8 |
Bug | Closed | Major | Fixed | Unassigned | Thomas Neidhart | Thomas Neidhart | 17/Nov/13 16:04 | 09/Nov/14 14:31 | 17/Nov/13 18:31 | 4.0-alpha1 | 4.0 | 0 | 0 | Java 8 will introduce new default methods for the Map interface which clash with the existing method "V remove(K key1, K key2)" in our MultiKeyMap interface. To avoid future problems rename the method (and other similar methods with more multi key arguments) to a more specific version: * V removeMultiKey(K key1, K key2, ...) * V removeKey(K key1, K key2, ...) |
6 years, 18 weeks, 2 days ago | 358997 | No Perforce job exists for this issue. | 0 | 359287 | 0|i1pvwf: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-500 | Rename MultiMap.remove(K, V) to avoid clashes with newly introduced default methods in Java 8 |
Bug | Closed | Major | Fixed | Unassigned | Thomas Neidhart | Thomas Neidhart | 17/Nov/13 16:02 | 09/Nov/14 14:31 | 17/Nov/13 17:10 | 4.0-alpha1 | 4.0 | 0 | 0 | Java 8 will introduce new default methods for the Map interface which clash with the existing method "V remove(K key, V value)" in our MultiMap interface. To avoid future problems rename the method to a more specific version and change the return type to be more logical. Brief discussion on the ml favored either: * boolean removeMapping(K key, V value) * boolean removeValue(K key, V value) |
6 years, 18 weeks, 2 days ago | 358996 | No Perforce job exists for this issue. | 0 | 359286 | 0|i1pvw7: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-496 | UnmodifiableBoundedCollection does not implement Unmodifiable marker interface |
Bug | Closed | Major | Fixed | Unassigned | Thomas Neidhart | Thomas Neidhart | 11/Nov/13 16:42 | 09/Nov/14 14:31 | 11/Nov/13 16:47 | 4.0-alpha1 | 4.0 | 0 | 0 | The UnmodifiableBoundedCollection does not implement the Unmodifiable interface. | 6 years, 19 weeks, 1 day ago | 357969 | No Perforce job exists for this issue. | 0 | 358259 | 0|i1ppk7: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-495 | UnmodifiableTrie should not decorate an already unmodifiable Trie |
Bug | Closed | Minor | Fixed | Unassigned | Thomas Neidhart | Thomas Neidhart | 11/Nov/13 16:25 | 09/Nov/14 14:31 | 11/Nov/13 16:30 | 4.0-alpha1 | 4.0 | 0 | 0 | An already unmodifiable trie was decorated again. To be consistent with the other Unmodifiable wrappers, in this case the object itself shall be returned. Also the return type shall be changed to Trie. |
6 years, 19 weeks, 1 day ago | 357967 | No Perforce job exists for this issue. | 0 | 358257 | 0|i1ppjr: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-597 | Correction of Javadoc for org.apache.commons.collections4.functors.CatchAndRethrowClosure |
Bug | Resolved | Trivial | Fixed | Gary D. Gregory | Enrique | Enrique | 20/Oct/16 13:47 | 18/Mar/20 02:58 | 21/Oct/16 05:53 | 21/Oct/16 05:53 | 4.0, 4.1 | 4.2 | Functor | 0 | 2 | 300 | 300 | 0% | Correct the javadoc for org.apache.commons.collections4.functors.CatchAndRethrowClosure, replacing: CollctionUtils.forAllDo(strList, writer); by: CollectionUtils.forAllDo(strList, writer); |
0% | 0% | 300 | 300 | documentation | 3 years, 21 weeks, 4 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i355kf: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-553 | TransformedMultiValuedMap.equals() fails when comparing the value with itself |
Bug | Closed | Major | Fixed | Unassigned | M Kim | M Kim | 16/Feb/15 16:09 | 27/Nov/15 21:11 | 07/Apr/15 11:41 | 4.0 | 4.1 | Map | 0 | 1 | COLLECTIONS-543 | TransformedMultiValuedMap.equals() does not return true when comparing a value of a Collection key with itself. Is it allowed to put Collection as a key in TransformedMultiValuedMap at all? If not, I think it should be specified in the document. Or, equals() should be fixed accordingly. Reproduce step {code:title=Test.java|borderStyle=solid} public void test() { TransformedMultiValuedMap map = TransformedMultiValuedMap.transformingMap((MultiValuedMap)new MultiValuedHashMap(),TransformerUtils.stringValueTransformer(), TransformerUtils.stringValueTransformer()); MultiValuedHashMap helperMap = new MultiValuedHashMap(); helperMap.put("KEY", "Value"); Collection key = helperMap.keySet(); map.put(key, "Hi"); Collection value = map.get(key); assertTrue("Contract failed: value.equals(value)", value.equals(value)); } {code} |
4 years, 50 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i25onj: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-545 | Undocumented performance issue in the removeAll method in CollectionUtils |
Bug | Closed | Trivial | Fixed | Unassigned | Oswaldo Olivo | Oswaldo Olivo | 12/Jan/15 06:04 | 27/Nov/15 21:11 | 23/Jan/15 09:34 | 4.0 | 4.1 | Collection | 0 | 1 | Ubuntu 14.04 | This bug is analogous to https://issues.apache.org/jira/browse/COLLECTIONS-544 The method removeAll in CollectionUtils is inefficient when the second parameter collection has a slow containment method. The following is the current implementation with its documentation: ============================ /** * Removes the elements in <code>remove</code> from <code>collection</code>. That is, this * method returns a collection containing all the elements in <code>c</code> * that are not in <code>remove</code>. The cardinality of an element <code>e</code> * in the returned collection is the same as the cardinality of <code>e</code> * in <code>collection</code> unless <code>remove</code> contains <code>e</code>, in which * case the cardinality is zero. This method is useful if you do not wish to modify * the collection <code>c</code> and thus cannot call <code>collection.removeAll(remove);</code>. * * @param <E> the type of object the {@link Collection} contains * @param collection the collection from which items are removed (in the returned collection) * @param remove the items to be removed from the returned <code>collection</code> * @return a <code>Collection</code> containing all the elements of <code>collection</code> except * any elements that also occur in <code>remove</code>. * @throws NullPointerException if either parameter is null * @since 4.0 (method existed in 3.2 but was completely broken) */ public static <E> Collection<E> removeAll(final Collection<E> collection, final Collection<?> remove) { return ListUtils.removeAll(collection, remove); } ======================================= We can notice the inefficiency by looking at the removeAll method in ListUtils. The removeAll method from ListUtils is implemented and documented as follows: ======================================= /** * Removes the elements in <code>remove</code> from <code>collection</code>. That is, this * method returns a list containing all the elements in <code>collection</code> * that are not in <code>remove</code>. The cardinality of an element <code>e</code> * in the returned collection is the same as the cardinality of <code>e</code> * in <code>collection</code> unless <code>remove</code> contains <code>e</code>, in which * case the cardinality is zero. This method is useful if you do not wish to modify * <code>collection</code> and thus cannot call <code>collection.removeAll(remove);</code>. * <p> * This implementation iterates over <code>collection</code>, checking each element in * turn to see if it's contained in <code>remove</code>. If it's not contained, it's added * to the returned list. As a consequence, it is advised to use a collection type for * <code>remove</code> that provides a fast (e.g. O(1)) implementation of * {@link Collection#contains(Object)}. * * @param <E> the element type * @param collection the collection from which items are removed (in the returned collection) * @param remove the items to be removed from the returned <code>collection</code> * @return a <code>List</code> containing all the elements of <code>c</code> except * any elements that also occur in <code>remove</code>. * @throws NullPointerException if either parameter is null * @since 3.2 */ public static <E> List<E> removeAll(final Collection<E> collection, final Collection<?> remove) { final List<E> list = new ArrayList<E>(); for (final E obj : collection) { if (!remove.contains(obj)) { list.add(obj); } } return list; } ======================================= In the case of ListUtils:removeAll, the inefficiency is properly documented. Perhaps the disclaimer about potential inefficiencies depending on the type of the parameter collection in ListUtils:removeAll should also be included in CollectionUtils:removeAll. |
Collections, documentaion, performance | 5 years, 8 weeks, 4 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i248xr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-548 | Performance issue in CompositeCollection::retainAll |
Bug | Closed | Minor | Won't Fix | Unassigned | Oswaldo Olivo | Oswaldo Olivo | 21/Jan/15 21:50 | 27/Nov/15 21:47 | 24/Jan/15 12:59 | 4.0 | Collection | 0 | 1 | Ubuntu 14.04 | There seems to be a performance problem with the function retainAll of CompositeCollection. This is analogous to https://issues.apache.org/jira/browse/COLLECTIONS-534 . The following is the code of the function: {code} /** * Retains all the elements in the specified collection in this composite collection, * removing all others. * <p> * This implementation calls <code>retainAll()</code> on each collection. * * @param coll the collection to remove * @return true if the collection was modified * @throws UnsupportedOperationException if retainAll is unsupported */ public boolean retainAll(final Collection<?> coll) { boolean changed = false; for (final Collection<E> item : all) { changed |= item.retainAll(coll); } return changed; } {code} The performance problem occurs when the underlying collections in the current collection have a slow retainAll method. Whenever we're relying on Collection::retainAll, slow cases tend to occur when the parameter collection has a slow contains method. The following test harness shows the performance degradation between using a list and using a set as a parameter, across different collection sizes. {code} public static void compositeCollectionRetainAllTest(boolean original) { int N=500000; ArrayList<Integer> firstArrayList=new ArrayList<Integer>(); ArrayList<Integer> secondArrayList=new ArrayList<Integer>(); for(int i=0;i<N;++i) { firstArrayList.add(new Integer(i)); secondArrayList.add(new Integer(N-1-i)); } CompositeCollection col = new CompositeCollection(firstArrayList); col.retainAll(original ? secondArrayList : (new HashSet<Integer>(secondArrayList))); } {code} In the following table "Original" corresponds to the time taken by the existing implementation of CompositeCollection::retainAll, "Repaired" to the time taken by the function invoked with the parameter converted into a set, and "Speed-up" to the speed-up obtained after the repair. N Original(s) Repaired(s) Speed-up(X) 10 1.04 1.04 1.00 100 1.04 1.05 0.99 1000 1.06 1.06 1.00 10000 1.12 1.10 1.01 100000 9.34 1.15 8.12 500000 > 300 1.29 > 232.55 If it's unacceptable to convert the parameter into a set before calling retainsAll, a solution would be to include a warning to the user in the documentation that the parameter should have a fast contains method when possible. |
performance | 5 years, 8 weeks, 3 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i24n0n: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-547 | Performance issue in SetUtils::isEqualSet |
Bug | Closed | Minor | Not A Problem | Unassigned | Oswaldo Olivo | Oswaldo Olivo | 21/Jan/15 21:10 | 27/Nov/15 21:47 | 22/Jan/15 09:18 | 4.0 | Set | 0 | 1 | Ubuntu 14.04 | There seems to be a performance problem with the function isEqualSet of SetUtils when the first parameter is of a collection type that has a slow containsAll/contains method. The following is the code of the function: {code} /** * Tests two sets for equality as per the <code>equals()</code> contract * in {@link java.util.Set#equals(java.lang.Object)}. * <p> * This method is useful for implementing <code>Set</code> when you cannot * extend AbstractSet. The method takes Collection instances to enable other * collection types to use the Set implementation algorithm. * <p> * The relevant text (slightly paraphrased as this is a static method) is: * <blockquote> * <p>Two sets are considered equal if they have * the same size, and every member of the first set is contained in * the second. This ensures that the <tt>equals</tt> method works * properly across different implementations of the <tt>Set</tt> * interface.</p> * * <p> * This implementation first checks if the two sets are the same object: * if so it returns <tt>true</tt>. Then, it checks if the two sets are * identical in size; if not, it returns false. If so, it returns * <tt>a.containsAll((Collection) b)</tt>.</p> * </blockquote> * * @see java.util.Set * @param set1 the first set, may be null * @param set2 the second set, may be null * @return whether the sets are equal by value comparison */ public static boolean isEqualSet(final Collection<?> set1, final Collection<?> set2) { if (set1 == set2) { return true; } if (set1 == null || set2 == null || set1.size() != set2.size()) { return false; } return set1.containsAll(set2); } {code} The problem is that in the last return statement, the function relies on the containsAll method of the class of the set1, which can be any type of collection. The following test harness shows the performance degradation between using a list and using a set as a first parameter, across different collection sizes. {code} public static void setUtilsisEqualSetTest(boolean original) { int N=500000; ArrayList<Integer> firstArrayList=new ArrayList<Integer>(); ArrayList<Integer> secondArrayList=new ArrayList<Integer>(); for(int i=0;i<N;++i) { firstArrayList.add(new Integer(i)); secondArrayList.add(new Integer((N-1)-i)); } SetUtils.isEqualSet(original?firstArrayList:(new HashSet<Integer>(firstArrayList)),secondArrayList); {code} In the following table "Original" corresponds to the time taken by the existing implementation of SetUtils::isEqualSet, "Repaired" to the time taken by the function invoked with the first parameter converted into a set, and "Speed-up" to the speed-up obtained after the repair. N Original(s) Repaired(s) Speed-up(X) 10 1.01 1.02 0.99 100 1.02 1.02 1 1000 1.04 1.04 1 10000 1.15 1.09 1.05 100000 9.33 1.11 8.40 500000 > 300 1.26 > 238.09 One way to deal with this would be to call the CollectionUtils::containsAll method instead of Collection::containsAll, since it has a linear time implementation instead of quadratic, and can handle the types of isEqualSet. Another solution would be to include a warning to the user in the documentation that the first parameter should have a fast containment method when possible. |
perfomance | 5 years, 8 weeks, 5 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i24mx3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-543 | AbstractCollectionDecorator should not delegate equals and hashcode |
Bug | Closed | Major | Fixed | Unassigned | Thomas Neidhart | Thomas Neidhart | 07/Jan/15 22:05 | 27/Nov/15 21:11 | 12/Jan/15 15:21 | 4.0 | 4.1 | 0 | 0 | COLLECTIONS-512, COLLECTIONS-553 | In order to preserve the symmetry of equals the AbstractCollectionDecorator shall not forward calls to equals and hashcode to the decorated collection. The test for equality usually also includes a test for the specific interface, e.g. List, which the collection decorator does not implement. The relevant sub-classes like AbstractListDecorator can delegate the calls to safely fulfill the Collections contract. |
5 years, 10 weeks, 1 day ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i241uf: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-531 | Generic Wildcards specified in CollectionUtils#isEqualCollection(Collection, Collection, Equator) may throw ClassCastException in certain cases |
Bug | Closed | Minor | Fixed | Unassigned | Dipanjan Laha | Dipanjan Laha | 27/May/14 10:13 | 27/Nov/15 21:11 | 29/May/14 18:34 | 4.0 | 4.1 | Collection | 0 | 1 | CollectionUtils#isEqualCollection(Collection, Collection, Equator) is defined as {code} public static boolean isEqualCollection(final Collection<?> a, final Collection<?> b, final Equator<?> equator) { ... } {code} This makes it possible to invoke it with a code like {code} public static class IntegerEquator implements Equator<Integer> { public boolean equate(Integer o1, Integer o2) { return o1.intValue() == o2.intValue(); } public int hash(Integer o) { return o.intValue(); } } @Test public void test() { List<Long> longList = Arrays.asList(1L, 2L); List<Integer> intList = Arrays.asList(1, 2); assertTrue(CollectionUtils.isEqualCollection(longList, intList, new IntegerEquator())); } {code} which compiles perfectly but throws a ClassCastException as Long cannot be cast to an Integer. However, the generics should be defined such that this is stopped at compile time itself. If we modify the method to something like {code} public static <E> boolean isEqualCollection(final Collection<? extends E> a, final Collection<? extends E> b, final Equator<? super E> equator) { ... } {code} the above example would give a compile time error. imho we should modify this method with bounded wildcards. I don't think this change would break any existing binaries if the method is being used correctly, otherwise it is probably throwing ClassCastExceptions anyway. Test case attached |
5 years, 42 weeks, 5 days ago | 394974 | No Perforce job exists for this issue. | 1 | 395109 | 0|i1w06v: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-592 | Deletions/insertions get lost in the ReplacementsFinder if they're at the end of the compared sequences |
Bug | Open | Minor | Unresolved | Unassigned | Alexis Mestag | Alexis Mestag | 19/Jun/16 22:19 | 18/Mar/20 02:08 | 20/Jun/16 07:31 | 4.0, 4.1 | 0 | 1 | In the {{sequence}} package, when comparing 2 lists with a {{SequencesComparator}} and visiting the {{EditScript}} with a {{ReplacementsFinder}}, pending deletions and insertions get lost in the {{ReplacementsFinder}} when they're at the end of the sequences. The {{ReplacementsFinder}} stores the deletions and insertions until it encounters a {{KeepCommand}}, when it flushes the pending commands by triggering the {{handleReplacement}} method of its {{ReplacementHandler}}. The problem is, when edit commands are at the end of the sequences, the {{ReplacementsFinder}} will never encounter a {{KeepCommand}} to flush them, so they're stuck here and will never be handed over the {{ReplacementHandler}}. To fix this behavior in client code, one can manually call {{ReplacementsFinder.visitKeepCommand(null)}} after the {{EditScript.visit()}} call. I patched this bug in the library by adding a {{CommandVisitor.endOfVisit}} method and calling it at the end of the {{EditScript.visit}} method, so it allows to flush the pending deletions/insertions in the {{ReplacementsFinder}} when the end of the {{EditScript}} is reached. |
3 years, 39 weeks, 2 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 1 | 9223372036854775807 |
Patch
|
0|i2zpnr: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-577 | PatriciaTrie bugs when only a few bits change |
Bug | Closed | Critical | Duplicate | Unassigned | Chris Duncan | Chris Duncan | 25/Sep/15 22:27 | 27/Nov/15 21:47 | 28/Sep/15 09:45 | 4.0 | 4.1 | Map | 0 | 1 | I have a bug report for you, for the class AbstractPatriciaTrie. It has to do with how you handle bits when they are very close to each other. For example, some of your methods seem to think that if the only difference between a prefix and a longer string, is a single additional bit, then they are actually the same data. Or if the only difference is some number of zero bits, then it also thinks they are the same data. There are also MANY situations where the prefixMap does not return all the strings that start with the prefix. Can you also make AbstractPatriciaTrie public, and your other package level methods into protected level, that way I don't have to copy the entire class and subclasse's code out into another class just to extend it? thank you, Chris Duncan (github user: VEQRYN) |
4 years, 25 weeks, 1 day ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i2ll0f: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-579 | PassiveExpiringMap doesn't work when the key is a byte array |
Bug | Closed | Major | Invalid | Unassigned | Roger R Andrews | Roger R Andrews | 04/Nov/15 12:48 | 27/Nov/15 21:47 | 04/Nov/15 13:19 | 4.0 | Map | 0 | 1 | GNU/Linux Ubuntu 15.10 64 bits, OpenJDK 1.8.0_65 | When you put a (key,value) pair in a PassiveExpiringMap and the key is byte[] you can't retrieve it. Code to reproduce the problem: byte[] key = {0,0,0,1}; PassiveExpiringMap<byte[],byte[]> map = new PassiveExpiringMap<byte[],byte[]> (); map.put(key,key); byte[] queryKey = {0,0,0,1}; //this should be true map.containsKey(queryKey) == false |
4 years, 19 weeks, 5 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 |
Important
|
0|i2nxsf: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-516 | NullPointerException in MapUtils.toProperties |
Bug | Closed | Major | Fixed | Unassigned | Cyrille Artho | Cyrille Artho | 10/Apr/14 04:39 | 27/Nov/15 21:11 | 19/May/14 20:38 | 4.0 | 4.1 | Collection | 0 | 1 | Mac OS 10.9, Java 6 | calling MapUtils.toProperties with a map having null entries results in a NullPointerException. In this case the Map has only entry <null, null>. However, javadoc states "A null input will return an empty properties object." so (1) this should be clarified as it would only apply to the map reference itself, not its contents, or (2) an empty property object should be generated for null entries in the map as well. |
5 years, 44 weeks, 1 day ago | 385961 | No Perforce job exists for this issue. | 1 | 386225 | 0|i1uhnb: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-515 | ClassCastException in LazySortedMap when used with equals/transformers |
Bug | Closed | Major | Invalid | Unassigned | Cyrille Artho | Cyrille Artho | 10/Apr/14 04:36 | 27/Nov/15 21:47 | 10/Apr/14 20:46 | 4.0 | Collection, Map | 0 | 1 | Mac OS 10.9, Java 6 | When LazySortedMap is used by equals, the result is java.lang.ClassCastException: org.apache.commons.collections4.map.LazySortedMap cannot be cast to java.lang.String This seems to be odd, as the use of the different transformations should not result in internal casting to String. See the attached unit test to reproduce. |
5 years, 49 weeks, 5 days ago | 385960 | No Perforce job exists for this issue. | 1 | 386224 | 0|i1uhn3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-514 | NullPointerException in MapBackedSet.mapBackedSet |
Bug | Closed | Major | Invalid | Unassigned | Cyrille Artho | Cyrille Artho | 10/Apr/14 04:31 | 27/Nov/15 21:47 | 10/Apr/14 20:59 | 4.0 | Bag, Collection, Set | 0 | 1 | MacOS 10.9, Java 6 | It seems that addAll has issues with adding a set that is backed by a singleton map with entry null -> null. However, the javadoc of the involved classes does not state that null entries are disallowed. Either the code should allow adding a null entry to a bag, or the documentation should state that null entries are not allowed. See the attached unit test in JUnit format to reproduce the problem. |
5 years, 49 weeks, 5 days ago | 385959 | No Perforce job exists for this issue. | 1 | 386223 | 0|i1uhmv: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-513 | NullPointerException in SwitchTransformer.transform |
Bug | Closed | Major | Invalid | Unassigned | Cyrille Artho | Cyrille Artho | 10/Apr/14 02:00 | 27/Nov/15 21:47 | 10/Apr/14 20:28 | 4.0 | Functor | 0 | 1 | Mac OS 10.9, Java 6 and Java 7 | A relatively complex test case generated by Randoop results in a NullPointerException in SwitchTransformer.transform. I'm not sure if this is an incorrect usage of the method, or if it is a real bug. |
5 years, 49 weeks, 5 days ago | 385946 | No Perforce job exists for this issue. | 1 | 386210 | 0|i1uhjz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-512 | equals/hashCode mismatch |
Bug | Closed | Major | Fixed | Unassigned | Cyrille Artho | Cyrille Artho | 10/Apr/14 01:56 | 27/Nov/15 21:11 | 02/Jan/15 13:03 | 4.0 | 4.1 | Collection, Comparator | 0 | 2 | COLLECTIONS-543 | Mac OS 10.9, Java 6 and Java 7 | We used Randoop on the collection classes, which found several test cases where two objects are equal but their hash code differs. I will attach a file containing two test cases that are different; the other tests seem to be longer versions showing the same issue. |
5 years, 11 weeks, 4 days ago | 385944 | No Perforce job exists for this issue. | 2 | 386208 | 0|i1uhjj: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-518 | AbstractIterableGetMapDecorator should be abstract |
Bug | Reopened | Minor | Unresolved | Unassigned | Dipanjan Laha | Dipanjan Laha | 14/Apr/14 05:36 | 31/May/15 18:52 | 4.0 | 5.0 | Map | 0 | 1 | AbstractIterableGetMapDecorator should be abstract, but is not | 4 years, 42 weeks, 2 days ago | 386509 | No Perforce job exists for this issue. | 1 | 386773 | 0|i1ul0n: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-509 | Clarify javadoc of CollectionBag |
Bug | Closed | Major | Fixed | Unassigned | Thomas Neidhart | Thomas Neidhart | 08/Mar/14 18:45 | 27/Nov/15 21:11 | 08/Mar/14 18:47 | 4.0 | 4.1 | 0 | 0 | The javadoc of CollectionBag should clarify which methods have changed wrt the original Bag interface. | 6 years, 2 weeks, 3 days ago | 377975 | No Perforce job exists for this issue. | 0 | 378267 | 0|i1t4of: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-507 | ComparatorUtils.chainedComparator(..) should not force the objects to implement Comparable |
Bug | Closed | Major | Fixed | Unassigned | Gerson | Gerson | 12/Feb/14 20:29 | 27/Nov/15 21:11 | 12/Feb/14 21:18 | 4.0 | 4.1 | Comparator | 0 | 1 | 6 years, 5 weeks, 6 days ago | 373338 | No Perforce job exists for this issue. | 0 | 373639 | 0|i1sc6n: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-474 | Exception in ListOrderedMap#putAll if map contains null values |
Bug | Closed | Major | Fixed | Unassigned | Ning Chen | Ning Chen | 24/Jun/13 18:22 | 18/Mar/20 02:15 | 09/Nov/14 14:31 | 30/Jun/13 20:10 | 4.0 | 4.0-alpha1, 4.0 | Map | 0 | 1 | java 1.7.0_09 | Dear apache developers, thanks for the great project. Recently, I encountered an IndexOutOfBoundsException in ListOrderedMap in the latest revision (r1495998) with the crash stack trace: Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 2, Size: 1 at java.util.ArrayList.add(ArrayList.java:367) at org.apache.commons.collections4.map.ListOrderedMap.put(ListOrderedMap.java:448) at org.apache.commons.collections4.map.ListOrderedMap.putAll(ListOrderedMap.java:246) at Test.main(Test.java:15) I've also attached a test case that can reproduce this crash. I think this test case actually reveals the bug reported in COLLECTIONS-411 (https://issues.apache.org/jira/browse/COLLECTIONS-411). However, it seems that the original patch for COLLECTIONS-411 missed a corner case. Could you please check if this is indeed a bug? Thanks! |
6 years, 38 weeks, 2 days ago | 334836 | No Perforce job exists for this issue. | 1 | 335160 | 0|i1lrbb: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-566 | IteratorUtils.collatedIterator do not use natural ordering if no comparator was provided |
Bug | Closed | Major | Fixed | Unassigned | Thomas Neidhart | Thomas Neidhart | 04/Jun/15 20:19 | 27/Nov/15 21:11 | 04/Jun/15 20:36 | 4.0 | 4.1 | 0 | 0 | In case a null comparator was provided natural ordering should be used, as stated in the javadoc. In fact an exception is thrown the first time the returned iterator is used. |
4 years, 41 weeks, 5 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i2fnj3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-570 | All decorators shall throw a NullPointerException if the decorated argument is null |
Bug | Closed | Minor | Fixed | Unassigned | Thomas Neidhart | Thomas Neidhart | 22/Jun/15 09:50 | 27/Nov/15 21:11 | 22/Jun/15 13:02 | 4.0 | 4.1 | 0 | 0 | To be consistent, the constructor shall throw a NullPointerException instead of a IllegalArgumentException if the argument is null. | 4 years, 39 weeks, 1 day ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i2gbtb: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-559 | Objects which are not of type V can be placed in a MultiValueMap<K,V>. |
Bug | Closed | Major | Invalid | Unassigned | Pétur Ingi Egilsson | Pétur Ingi Egilsson | 01/Apr/15 19:26 | 01/Apr/15 19:41 | 01/Apr/15 19:41 | 4.0 | KeyValue | 0 | 1 | 600 | 600 | 0% | java version "1.8.0_25" Java(TM) SE Runtime Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) OS X 10.10 |
I declared a MultiValueMap as this: {code} MultiValueMap<Integer, Path> duplicates = new MultiValueMap<Integer, Path>(); {code} Elsewhere in code I doing (by accident) something in this direction {code} duplicates.put(number, new LinkedList<Path>()); {code} Exceptions were being thrown when values returned from the list could not be assigned to variables of type Path. {code:title=org.apache.commons.collections4.map.MultiValueMap.java} public Object put(final K key, final Object value) { ... {code} I propose that Object in the above decleration is changed to T. |
0% | 0% | 600 | 600 | 4 years, 50 weeks, 6 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i27nsv: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-558 | ListOrderedSet#remove(int) should return E instead of Object |
Bug | Closed | Major | Fixed | Unassigned | Felix Rabe | Felix Rabe | 25/Mar/15 14:46 | 27/Nov/15 21:11 | 25/Mar/15 16:03 | 4.0 | 4.1 | Set | 0 | 1 | Since {{List#remove(int)}} returns {{E}} the implementation in {{ListOrderedSet}} should also return {{E}}. Minimal example that fails to compile: {code:java} ListOrderedSet<String> los = new ListOrderedSet<String>(); los.add("foo"); String s = los.remove(0); {code} |
4 years, 51 weeks, 6 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i27c8f: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-576 | MultiKey subclassing has deserialization problem since COLLECTIONS-266: either declare protected readResolve() or MultiKey must be final |
Bug | Closed | Major | Fixed | Unassigned | Stephan Roch | Stephan Roch | 03/Sep/15 08:44 | 27/Nov/15 21:11 | 28/Sep/15 08:54 | 4.0 | 4.1 | KeyValue | 0 | 1 | COLLECTIONS-266 | MultiKey from collections 4 provides a transient hashCode and a *private* readResolve to resolve COLLECTIONS-266: Issue with MultiKey when serialized/deserialized via RMI. Unfortunately the solution does not work in case of *subclassing*: readResolve in MultiKey should be declared *protected* readResolve() to be called during deserialization of the subclass. Otherwise MultiKey must be final to avoid such subclassing. *Testcase*: {code:java|title=MultiKeySerializationTest.java} package de.ivu.test.common.collections4; import static org.junit.Assert.assertEquals; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import org.apache.commons.collections4.keyvalue.MultiKey; import org.junit.Test; public class MultiKeySerializationTest { @Test @SuppressWarnings("unchecked") public void testReadResolveEqualHashCode() throws IOException, ClassNotFoundException { class MultiKey2<A, B> extends MultiKey { private static final long serialVersionUID = 1928896152249821416L; public MultiKey2(A key1, B key2) { super(key1, key2); } public A getFirst() { return (A) getKey(0); } public B getSecond() { return (B) getKey(1); } // FIXME: MultiKey should either declare protected readResolve() or must be final. } MultiKey2<String, String> one = new MultiKey2<>("bla", "blub"); System.out.println(one.hashCode()); ByteArrayOutputStream byteOut = new ByteArrayOutputStream(); ObjectOutputStream out = new ObjectOutputStream(byteOut); out.writeObject(one); out.close(); byte[] serialized = byteOut.toByteArray(); ByteArrayInputStream byteIn = new ByteArrayInputStream(serialized); ObjectInputStream in = new ObjectInputStream(byteIn); MultiKey2<String, String> two = (MultiKey2<String, String>) in.readObject(); System.out.println(two.hashCode()); assertEquals("hashCode must be equal - please check for protected readResolve in MultiKey*", one.hashCode(), two.hashCode()); } } {code} *Fix:* {code:java|title=MultiKey.java} @@ -274,7 +274,7 @@ * only stable for the same process). * @return the instance with recalculated hash code */ - private Object readResolve() { + protected Object readResolve() { calculateHashCode(keys); return this; } {code} |
4 years, 25 weeks, 1 day ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i2jqh3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-506 | Result of CollectionUtils are different between version 3.2.1 and version 4.0 |
Bug | Closed | Major | Fixed | Unassigned | Anthony Communier | Anthony Communier | 22/Dec/13 19:13 | 27/Nov/15 21:11 | 31/Dec/13 16:25 | 4.0 | 4.1 | 0 | 1 | CollectionUtils V3 uses equals to compute results but not CollectionUtils v4 (it seems to use ==) The following exemple with subtract method : List<ObjectTest> listA = new ArrayList<ObjectTest>(); List<ObjectTest> listB = new ArrayList<ObjectTest>(); listA.add(new ObjectTest("Test1")); listA.add(new ObjectTest("Test2")); listA.add(new ObjectTest("Test3")); listB.add(new ObjectTest("Test1")); listB.add(new ObjectTest("Test2")); Collection<?> res1 = org.apache.commons.collections.CollectionUtils.subtract(listA, listB); System.out.println("Res1 size = " +res1.size()); Collection<?> res2 = org.apache.commons.collections4.CollectionUtils.subtract(listA, listB); System.out.println("Res2 size = " +res2.size()); Produces this : Res1 size = 1 Res2 size = 3 The new behaviour is not useful. It would be better to have the V3 behaviour |
6 years, 11 weeks, 5 days ago | 365027 | No Perforce job exists for this issue. | 1 | 365335 | 0|i1qx3b: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-504 | CompositeMap should support compositing of maps of derived types |
Bug | Closed | Minor | Invalid | Unassigned | Peter Cooper Jr. | Peter Cooper Jr. | 03/Dec/13 20:33 | 04/Dec/13 15:32 | 04/Dec/13 12:56 | 4.0 | Map | 0 | 1 | I'm attempting to composite two maps, one of which is a {{Map<String, String>}} and the other of which is a {{Map<String, Object>}}. I would have expected that I could composite them into a {{CompositeMap<String, Object>}}, but the constructors of CompositeMap expect all of the maps being composited to have exactly the same type arguments. That is, I think the constructors should take arguments of {{Map<? extends K, ? extends V>}} instead of what they currently have of {{Map<K, V>}}, much like most collection methods, since there shouldn't be a problem accepting type arguments that are subtypes of the composite map types. Thanks! |
6 years, 15 weeks, 6 days ago | 361767 | No Perforce job exists for this issue. | 0 | 362064 | 0|i1qczz: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-526 | PatriciaTrie |
Bug | Closed | Critical | Duplicate | Unassigned | zigler zhang | zigler zhang | 08/May/14 04:38 | 08/May/14 06:04 | 08/May/14 06:04 | 4.0 | Collection | 0 | 1 | COLLECTIONS-525 | android | the result of trie tree prefixMap function is inconsistent. it would contain a key but the size is 0; some unittest codes as below: PatriciaTrie<String> aTree = new PatriciaTrie<String> (); aTree.put("点评", "测试"); aTree.put("书评", "测试"); assertTrue(aTree.prefixMap("点").containsKey("点评")); //pass assertEquals("测试", aTree.prefixMap("点").get("点评")); //pass assertFalse(aTree.prefixMap("点").isEmpty()); //fail assertEquals(1, aTree.prefixMap("点").size()); //fail assertEquals(1, aTree.prefixMap("点").keySet().size()); //fail assertEquals(1, aTree.prefixMap("点").entrySet().size()); //fail assertEquals(1, aTree.prefixMap("点评").values().size()); //fail |
5 years, 45 weeks, 5 days ago | 391330 | No Perforce job exists for this issue. | 0 | 391550 | 0|i1vedz: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-525 | PatriciaTrie |
Bug | Closed | Critical | Fixed | Unassigned | zigler zhang | zigler zhang | 08/May/14 04:38 | 27/Nov/15 21:11 | 01/Jan/15 21:11 | 4.0 | 4.1 | Collection | 0 | 1 | COLLECTIONS-526 | android | the result of trie tree prefixMap function is inconsistent. it would contain a key but the size is 0; some unittest codes as below: PatriciaTrie<String> aTree = new PatriciaTrie<String> (); aTree.put("点评", "测试"); aTree.put("书评", "测试"); assertTrue(aTree.prefixMap("点").containsKey("点评")); //pass assertEquals("测试", aTree.prefixMap("点").get("点评")); //pass assertFalse(aTree.prefixMap("点").isEmpty()); //fail assertEquals(1, aTree.prefixMap("点").size()); //fail actural 0 assertEquals(1, aTree.prefixMap("点").keySet().size()); //fail actural 0 assertEquals(1, aTree.prefixMap("点").entrySet().size()); //fail actural 0 assertEquals(1, aTree.prefixMap("点评").values().size()); //fail actural 0 |
5 years, 11 weeks, 5 days ago | 391329 | No Perforce job exists for this issue. | 1 | 391549 | 0|i1vedr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-537 | PredicateUtils (all|any)Predicate type misbehaviour Array vs. Collection |
Bug | Closed | Major | Fixed | Unassigned | Frank Jakop | Frank Jakop | 13/Nov/14 12:47 | 27/Nov/15 21:11 | 30/Dec/14 18:25 | 4.0 | 4.1 | Functor | 0 | 1 | Migrating from collections-generic to collections4 we encountered a type problem with PredicateUtils. When you look at the method anyPredicate(), the signature with array is typed with "Predicate<? super T>" whereas the signature with Collection is typed "? extends Predicate<T>", so the both methods are not equivalent. We think both methods should have the same types, so it would not break compatibility with a lot of legacy code. |
5 years, 12 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i22bvr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-534 | Performance bug in CollectionBag::retainAll |
Bug | Closed | Major | Fixed | Unassigned | Oswaldo Olivo | Oswaldo Olivo | 15/Oct/14 21:01 | 27/Nov/15 21:11 | 19/Oct/14 12:44 | 4.0 | 4.1 | Bag, Collection | 0 | 1 | Ubuntu 12.04 | Hi, There seems to be a performance bug in the method retainAll in the CollectionBag class. The problem is that the code is checking containment over the parameter collection, which could be expensive for some types of collections like ArrayLists. One solution could be to convert the Collection into a HashSet and check containment in the HashSet. If this is done, then running retainAll on a 1,000,000 collection would take less than 2 seconds instead of 27 mins, according to my experiments. ____________________________________________ Here's a function to expose the bug: public static void collectionBagRetainAllTest() { ArrayList<Integer> coll=new ArrayList<Integer>(); for(int i=0;i<=1000000;++i) coll.add(new Integer(i)); TreeBag<Integer> treeBag=new TreeBag<Integer>(coll); CollectionBag<Integer> bag = new CollectionBag<Integer>(treeBag); bag.retainAll(coll); } _____________________________________ Here's a proposed patch: public boolean retainAll(final Collection<?> coll) { if (coll != null) { boolean modified = false; final Iterator<E> e = iterator(); HashSet<Object> set=new HashSet<Object>(coll); while (e.hasNext()) { if (!set.contains(e.next())) { e.remove(); modified = true; } } return modified; } else { // let the decorated bag handle the case of null argument return decorated().retainAll(null); } } _____________________________________ |
perfomance | 5 years, 22 weeks, 2 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i217vb: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-391 | Inconsistent Javadoc comment and code for toProperties(final Map<K, V>) in org.apache.commons.collections.MapUtils |
Bug | Closed | Major | Fixed | Unassigned | SHIN HWEI TAN | SHIN HWEI TAN | 08/Jan/12 08:38 | 18/Mar/20 03:00 | 09/Nov/14 14:31 | 09/Apr/12 18:03 | 4.0, 4.x | 4.0-alpha1, 4.0 | Collection | 0 | 0 | 120 | 120 | 0% | Platform Indepedent | The Javadoc comment below states that the parameter map "..., may not be null": /** .. * @param map the map to convert to a Properties object, may not be null * @return the properties object */ public static <K, V> Properties toProperties(final Map<K, V> map) { Properties answer = new Properties(); if (map != null) { ... } return answer; } However, the method return normally without throwing any exception when called with null. Suggested Fixes: 1. Change "@param map the map to convert to a Properties object, may not be null" to "@param map the map to convert to a Properties object, may be null" or 2. Remove "may not be null" from @param. |
0% | 0% | 120 | 120 | javadoc, null | 7 years, 50 weeks, 1 day ago | 223174 | No Perforce job exists for this issue. | 0 | 164364 | 0|i0shtj: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-390 | Inconsistent Javadoc comment and code for mapTransformer(Map<? super I, ? extends O>) in org.apache.commons.collections.TransformerUtils |
Bug | Closed | Major | Duplicate | Unassigned | SHIN HWEI TAN | SHIN HWEI TAN | 08/Jan/12 08:31 | 24/Jun/13 19:34 | 08/Jan/12 08:32 | 4.0 | Buffer | 0 | 0 | 120 | 120 | 0% | Platform Independent | The Javadoc comment below states that the method "throws IllegalArgumentException if the map is null": /** .... * @param map the map to use to transform the objects * @return the transformer * @throws IllegalArgumentException if the map is null */ public static <I, O> Transformer<I, O> mapTransformer(Map<? super I, ? extends O> map) { return MapTransformer.mapTransformer(map); } However, the method returns a NULL_INSTANCE object instead of throwing IllegalArgumentException when called with null. Suggested Fixes: 1. Change "@throws IllegalArgumentException if the map is null" and "@return" to "@return NULL_INSTANCE if the map is null". or 2. Remove the entire "throws IllegalArgumentException if the map is null". |
0% | 0% | 120 | 120 | 8 years, 11 weeks, 2 days ago | 223173 | No Perforce job exists for this issue. | 0 | 164365 | 0|i0shtr: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-389 | Inconsistent Javadoc comment and code for mapTransformer(Map<? super I, ? extends O>) in org.apache.commons.collections.TransformerUtils |
Bug | Closed | Major | Fixed | Unassigned | SHIN HWEI TAN | SHIN HWEI TAN | 08/Jan/12 08:31 | 09/Nov/14 14:31 | 09/Apr/12 17:21 | 4.0, 4.x | 4.0-alpha1, 4.0 | Collection | 0 | 0 | 120 | 120 | 0% | Platform Independent | The Javadoc comment below states that the method "throws IllegalArgumentException if the map is null": /** .... * @param map the map to use to transform the objects * @return the transformer * @throws IllegalArgumentException if the map is null */ public static <I, O> Transformer<I, O> mapTransformer(Map<? super I, ? extends O> map) { return MapTransformer.mapTransformer(map); } However, the method returns a NULL_INSTANCE object instead of throwing IllegalArgumentException when called with null. Suggested Fixes: 1. Change "@throws IllegalArgumentException if the map is null" and "@return" to "@return NULL_INSTANCE if the map is null". or 2. Remove the entire "throws IllegalArgumentException if the map is null". |
0% | 0% | 120 | 120 | javadoc, null | 7 years, 50 weeks, 1 day ago | 223172 | No Perforce job exists for this issue. | 0 | 164366 | 0|i0shtz: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-388 | Inconsistent Javadoc comment and code for prototypeFactory(T) in org.apache.commons.collections.FactoryUtils |
Bug | Closed | Major | Fixed | Unassigned | SHIN HWEI TAN | SHIN HWEI TAN | 08/Jan/12 08:29 | 09/Nov/14 14:31 | 09/Apr/12 17:16 | 4.0, 4.x | 4.0-alpha1, 4.0 | Collection | 0 | 0 | 120 | 120 | 0% | Platform independent | The Javadoc comment below states that the method "throws IllegalArgumentException if the prototype is null": /** .. * @param prototype the object to clone each time in the factory * @return the <code>prototype</code> factory * @throws IllegalArgumentException if the prototype is null * @throws IllegalArgumentException if the prototype cannot be cloned */ public static <T> Factory<T> prototypeFactory(T prototype) { return PrototypeFactory.<T>prototypeFactory(prototype); } However, the method returns a NULL_INSTANCE object instead of throwing IllegalArgumentException when called with null. Suggested Fixes: 1. Change "@throws IllegalArgumentException if the prototype is null" and "@return" to "@return NULL_INSTANCE if the prototype is null". or 2. Remove the entire "throws IllegalArgumentException if the prototype is null". |
0% | 0% | 120 | 120 | javadoc, null | 7 years, 50 weeks, 1 day ago | 223171 | No Perforce job exists for this issue. | 0 | 164367 | 0|i0shu7: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-604 | More uniform safe-null methods in CollectionUtils |
Bug | Open | Minor | Unresolved | Bruno P. Kinoshita | Bruno P. Kinoshita | Bruno P. Kinoshita | 26/May/17 12:41 | 12/Nov/19 08:27 | 4.1 | Collection | 1 | 4 | COLLECTIONS-600 | Currently, there are 65 public methods in `CollectionUtils`. And 53 without the deprecated ones. Out of these, 24 handle `null` arguments. The remaining methods throw a `NullPointerException` (NPE) at some part of its code. The methods that handle nulls, throw NPE, or return empty columns, boolean values, or just doesn't do anything. As a user of the API, I would expect a more uniform behaviour across the methods of `CollectionUtils`. COLLECTIONS-600 address one of these methods. `removeAll` (2x) and `retainAll` (2x) both state that a NPE will be thrown if either parameter is `null`. However, they never check if the values are null, and instead allow the code to run until a NPE is thrown. And the following code shows that `isEmpty` and `isFull` behave differently too. {code:java} Collection<String> c = null; System.out.println(CollectionUtils.isEmpty(c)); // return true System.out.println(CollectionUtils.isFull(c)); // throws a NPE {code} If I don't have to worry about `null`s with `#isEmpty`, I would expect the same from its related-method `#isFull`. What would be a good approach for it? Define a behaviour to all methods? Or leave as is, but add more documentation? There are a few methods that can easily be updated to check for `null` values. Others would require a bit more thinking. An example if the method in question for COLLECTIONS-600. It checks equality of collections, and when both collections are `null`, it says that they are equals. Google Guava [Iterables#elementsEqual|https://github.com/google/guava/blob/312aeb938bd35b5b7c8930e19ff5d1ca38e49424/guava/src/com/google/common/collect/Iterables.java#L232] and [Iterators#elementsEqual|https://github.com/google/guava/blob/312aeb938bd35b5b7c8930e19ff5d1ca38e49424/guava/src/com/google/common/collect/Iterators.java#L274] do not check for null values, for what it is worth. |
18 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 1 | 9223372036854775807 | 0|i3fipr: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-709 | MultiSet.Entry::getCount() isn't 0 after removing the last element |
Bug | Closed | Minor | Fixed | Unassigned | Robert Wertman | Robert Wertman | 19/Jan/19 23:30 | 18/Mar/20 02:59 | 20/Jan/19 17:41 | 20/Jan/19 15:06 | 4.1, 4.2 | 4.3 | 0 | 1 | 0 | 1800 | Removing the final element(s) in a MultiSet doesn't set the count on a MultiSet.Entry to zero.
{code:java} protected int getCountAfterRemoval(MultiSet<String> multiset) { MultiSet.Entry<String> entry = multiset.entrySet().iterator().next(); entry.getCount(); // = 2 multiset.remove(entry.getElement()); entry.getCount(); // = 1 multiset.remove(entry.getElement()); return entry.getCount(); // Still = 1, should be 0 } {code} |
100% | 100% | 1800 | 0 | 1 year, 8 weeks, 2 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|yi03i8: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-721 | functors.InvokerTransformer backward incompatibility bug |
Bug | Closed | Major | Not A Bug | Unassigned | xia0c | xia0c | 16/Jun/19 21:48 | 18/Mar/20 02:59 | 24/Jul/19 18:57 | 24/Jul/19 18:56 | 4.1, 4.2, 4.3 | 0 | 3 | COLLECTIONS-580 | The following code snippets throw a NotSerializableException. It works well before commons-collections4 4.0 and commons-collection3. When I update it to 4.1 or newer versions, it failed.
{code:java} @Test public void Demo() throws IOException{ InvokerTransformer transformer = new InvokerTransformer("toString", new Class[]{}, new Object[]{}); Queue priorityQueue = new PriorityQueue(2, new TransformingComparator(transformer)); priorityQueue.add(1); ByteArrayOutputStream bout = new ByteArrayOutputStream(); ObjectOutputStream out = new ObjectOutputStream(bout); out.writeObject(priorityQueue); } {code} |
performance | 33 weeks, 6 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 |
Important
|
0|z03suo: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-722 | IteratorUtils.chainedIterator() Performance Degrades |
Bug | Open | Major | Unresolved | Unassigned | E P | E P | 27/Jun/19 14:10 | 18/Mar/20 02:08 | 01/Nov/19 22:17 | 4.1 | 0 | 2 | IteratorUtils.chainedIterator() performance degrades when chaining iterators with chained iterators. The slowdown appears to be exponential, based upon the number of chains created. The attached test shows the issue.
As a reference, the same test below works as expected using Google's Guava Iterator.concat() functionality. It is possible I am misusing the API, but the javadoc did not indicate as much. |
19 weeks, 4 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 1 | 9223372036854775807 | 0|z045w8: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-673 | ListUtils.partition potential integer overflow |
Bug | Resolved | Major | Fixed | Unassigned | John Mark | John Mark | 02/Feb/18 17:18 | 12/Jun/18 21:45 | 12/Jun/18 21:45 | 4.1 | 4.2 | List | 0 | 3 | When calling {{ListUtils.partition()}} with a large size and large list, it is possible that an integer overflow will occur in the {{size()}} method that causes incorrect behavior. This will occur when using a size that, when added to list.size() will be larger than {{Integer.MAX_VALUE}}
Current version of Guava's {{Lists.partition()}} handle this correctly, so perhaps the code for {{ListUtils.partition()}} needs to be updated based on the latest Guava code. A simple illustration of this: {code} List<String> aList = Arrays.asList("1", "2", "3", "4", "5"); List<List<String>> partitioned = ListUtils.partition(aList, Integer.MAX_VALUE); System.out.println("Number of partitions: " + partitioned.size()); for(List<String> l : partitioned) { System.out.println(l); } {code} The above code works correctly when using Guava's {{Lists.partition()}} instead. |
1 year, 40 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i3ppz3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-661 | Intermittent test failures in Windows for HashSetValuedHashMap |
Bug | Resolved | Major | Fixed | Bruno P. Kinoshita | Bruno P. Kinoshita | Bruno P. Kinoshita | 03/Oct/17 09:54 | 12/Oct/17 06:31 | 12/Oct/17 06:31 | 4.1 | 4.2 | Map | 0 | 3 | The collection HashSetValuedHashMap was added in 4.1. On Windows, test failures are not so common on JVM 8. But on Linux they are harder to happen (but still do [1], [2]). When using Windows and JVM 8, running tests on Eclipse, or Maven fail. But debugging on Windows with Eclipse sometimes work. Indicating it may be due to a concurrency issue, where debugging adds some extra time hiding the real issue. I have a few ideas of where/why it could be happening, but am without a Windows box for a few days as I'm travelling. I'm reading the codebase in the meantime, but if anybody feels like working on it, feel free to chime in and suggest a fix/patch. [1] https://travis-ci.org/apache/commons-collections/jobs/282169803 [2] http://markmail.org/thread/exwm7ggjtxzbtlkd |
2 years, 22 weeks, 5 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i3kthr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-660 | Uncomment test in AbstractMapTest regarding LRUMap equals |
Bug | Resolved | Minor | Fixed | Bruno P. Kinoshita | Bruno P. Kinoshita | Bruno P. Kinoshita | 03/Oct/17 09:41 | 04/Oct/17 04:44 | 04/Oct/17 04:39 | 4.1 | 4.2 | Map | 0 | 1 | AbstractMapTest has a [commented out|https://github.com/apache/commons-collections/blob/c8bdf60d1d0be609094e14054be0b9af0fb05521/src/test/java/org/apache/commons/collections4/map/AbstractMapTest.java#L1959] line, with a comment as follows: {quote}his fails for LRUMap because confirmed.equals() somehow modifies map, causing concurrent modification exceptions.{quote} While working on another test failing on Windows, I believe I've found the why for that comment, and how to fix it. Just need to finish debugging another part, and find a good Internet connection to push the fix. |
2 years, 23 weeks, 6 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 |
Patch
|
0|i3ktfz: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-657 | "union" method is resulting in data loss |
Bug | Closed | Critical | Invalid | Unassigned | Igor Savin | Igor Savin | 19/Sep/17 18:12 | 19/Sep/17 18:38 | 19/Sep/17 18:38 | 4.1 | 0 | 1 | Create 2 instances of StringReader from strings (1 and 2), put them into a list A. Create empty list B. Call CollectionUtils.union(A, B); Expected result: [1, 2] Actual result: [1, 1]. |
2 years, 26 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i3k8wv: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-656 | Fix site build on Java 8 |
Bug | Resolved | Minor | Fixed | Bruno P. Kinoshita | Bruno P. Kinoshita | Bruno P. Kinoshita | 12/Sep/17 10:42 | 13/Sep/17 07:52 | 13/Sep/17 07:52 | 4.1 | 4.2 | 0 | 2 | Building the current master branch from git fails with {noformat} [INFO] Generating "FindBugs" report --- findbugs-maven-plugin:2.5.5:findbugs [INFO] Locale is en [INFO] Fork Value is true [java] The following errors occurred during analysis: [java] Error scanning java/util/Map$Entry for referenced classes [java] java.lang.ArrayIndexOutOfBoundsException: 5735 [java] At org.objectweb.asm.ClassReader.readClass(Unknown Source) [java] At org.objectweb.asm.ClassReader.accept(Unknown Source) [java] At edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44) [java] At org.objectweb.asm.ClassReader.accept(Unknown Source) [java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110) [java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587) [java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76) [java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38) [java] At edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268) [java] At edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:891) [java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:222) [java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393) [java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317) [java] Error scanning java/util/Comparator for referenced classes [java] java.lang.ArrayIndexOutOfBoundsException: 1320 [java] At org.objectweb.asm.ClassReader.readClass(Unknown Source) [java] At org.objectweb.asm.ClassReader.accept(Unknown Source) [java] At edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44) [java] At org.objectweb.asm.ClassReader.accept(Unknown Source) [java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110) [java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587) [java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76) [java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38) [java] At edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268) [java] At edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:891) [java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:222) [java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393) [java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317) [java] Unable to get XClass for java/util/AbstractMap$SimpleEntry [java] java.lang.ArrayIndexOutOfBoundsException: 5735 [java] At org.objectweb.asm.ClassReader.readClass(Unknown Source) [java] At org.objectweb.asm.ClassReader.accept(Unknown Source) [java] At edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44) [java] At org.objectweb.asm.ClassReader.accept(Unknown Source) [java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110) [java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587) [java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76) [java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38) [java] At edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268) [java] At edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:891) [java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:222) [java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393) [java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317) [java] Unable to get XClass for org/apache/commons/collections4/map/StaticBucketMap$Node [java] java.lang.ArrayIndexOutOfBoundsException: 5735 [java] At org.objectweb.asm.ClassReader.readClass(Unknown Source) [java] At org.objectweb.asm.ClassReader.accept(Unknown Source) [java] At edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44) [java] At org.objectweb.asm.ClassReader.accept(Unknown Source) [java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110) [java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587) [java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76) [java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38) [java] At edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268) [java] At edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:891) [java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:222) [java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393) [java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317) ... {noformat} Tested locally, and updating the commons-parent version to 42, and specifying the findbugs version from the parent property seems to fix the issue. As it could affect other parts of the build/release artefacts, I'll send a pull request to allow others to review before the parent is updated. |
documentation, site | 2 years, 27 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 |
Patch
|
0|i3jyhr: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-717 | ObjectInputFilter REJECTED: class org.apache.commons.collections.functors.InstantiateFactory |
Bug | Open | Major | Unresolved | Unassigned | kirubakaran | kirubakaran | 20/May/19 13:31 | 05/Jul/19 15:24 | 4.1 | Functor | 0 | 2 | WebLogic 12.2.1.3 server | we have an object rejection issue with latest version of common collection for the class InstantiateFactory
we have set system property to enable unsafe serialization= true but still we have object rejection for org.apache.commons.collections.functors.InstantiateFactory. can you please help us to resolve the issue. Error log: DOMAIN] > <BEA-000000> <ObjectInputFilter REJECTED: class org.apache.commons.collections.functors.InstantiateFactory, array length: -1, nRefs: 3, depth: 2, bytes: 229, ex: n/a> ####<May 8, 2019 1:08:43,859 PM EDT> <Error> <RJVM> <nygindapnp613.us.db.com> <MS1> <ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'> <<WLS Kernel>> <> <a8f22bc1-d077-4f1b-be08-7677cfc592c6-00000005> <1557335323859> <[severity-value: 8] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-000503> <Incoming message header or abbreviation processing failed. java.io.InvalidClassException: filter status: REJECTED java.io.InvalidClassException: filter status: REJECTED at java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1255) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1878) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1751) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1560) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:431) at weblogic.rjvm.ClassTableEntry.readExternal(ClassTableEntry.java:106) at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:2118) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2067) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:431) at weblogic.rjvm.InboundMsgAbbrev.readObject(InboundMsgAbbrev.java:73) at weblogic.rjvm.InboundMsgAbbrev.read(InboundMsgAbbrev.java:45) at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:324) at weblogic.rjvm.MsgAbbrevInputStream.init(MsgAbbrevInputStream.java:219) at weblogic.rjvm.MsgAbbrevJVMConnection.dispatch(MsgAbbrevJVMConnection.java:556) at weblogic.rjvm.t3.MuxableSocketT3.dispatch(MuxableSocketT3.java:658) at weblogic.socket.BaseAbstractMuxableSocket.dispatch(BaseAbstractMuxableSocket.java:397) at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:981) at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:917) at weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:171) at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:30) at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:43) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:147) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:119) |
36 weeks, 4 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|z02uxs: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-554 | NullPointerException in CollectionUtils.partition |
Bug | Closed | Minor | Invalid | Unassigned | M Kim | M Kim | 16/Feb/15 16:33 | 27/Nov/15 21:47 | 07/Apr/15 12:41 | 4.1 | Collection | 0 | 1 | NullPointerException (NPE) is not suitably handled in CollectionUtils.partition. With a nullFactory, partitions.get(numberOfPredicates) can be null at line partitions.get(numberOfPredicates).add(element);. Stack trace: {code} test(Test)java.lang.NullPointerException at org.apache.commons.collections4.CollectionUtils.partition(CollectionUtils.java:1187) at Test.test(Test.java:18) {code} Test case: {code} public void test() { Collection input = CollectionUtils.permutations((java.util.Collection)new CircularFifoQueue(10)); Factory factory = FactoryUtils.nullFactory(); NullIsFalsePredicate p = new NullIsFalsePredicate(NullPredicate.nullPredicate()); Predicate[] predicates = p.getPredicates(); CollectionUtils.<java.lang.Object,java.util.Collection>partition((java.lang.Iterable)input, factory, predicates); } {code} |
4 years, 50 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i25opb: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-555 | Undefined NullPointerException in TreeBag.java |
Bug | Closed | Minor | Fixed | Unassigned | M Kim | M Kim | 16/Feb/15 17:03 | 27/Nov/15 21:11 | 17/Feb/15 22:03 | 4.1 | 4.1 | Bag | 0 | 1 | In add(final E object) method of TreeBag.java, the parameter object is not null-checked in throw IlligalArgumentException statement. Thus, it crashes with an inappropriate type of exceptions when the parameter, object is null. object can be null from the argument, transform(object) in TransformedCollection.add(final E object). I think object ==null should be added in the predicate of the throw IlligalArgumentException statement like below. {code} public boolean add(final E object) { if((object==null) || (comparator() == null && !(object instanceof Comparable))) { throw new IllegalArgumentException("Objects of type " + object.getClass() + " cannot be added to " + "a naturally ordered TreeBag as it does not implement Comparable"); } return super.add(object); } {code} |
5 years, 5 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i25oqv: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-544 | Undocumented performance issue in the retainAll method in CollectionUtils |
Bug | Closed | Trivial | Fixed | Unassigned | Oswaldo Olivo | Oswaldo Olivo | 12/Jan/15 05:55 | 27/Nov/15 21:11 | 12/Jan/15 14:06 | 4.1 | 4.1 | Collection | 0 | 2 | Ubuntu 14.04 | The method {{retainAll}} in {{CollectionUtils}} is inefficient when the parameter collection has a slow containment method. The following is the current implementation with its documentation: {noformat} /** * Returns a collection containing all the elements in <code>collection</code> * that are also in <code>retain</code>. The cardinality of an element <code>e</code> * in the returned collection is the same as the cardinality of <code>e</code> * in <code>collection</code> unless <code>retain</code> does not contain <code>e</code>, in which * case the cardinality is zero. This method is useful if you do not wish to modify * the collection <code>c</code> and thus cannot call <code>c.retainAll(retain);</code>. * * @param <C> the type of object the {@link Collection} contains * @param collection the collection whose contents are the target of the #retailAll operation * @param retain the collection containing the elements to be retained in the returned collection * @return a <code>Collection</code> containing all the elements of <code>collection</code> * that occur at least once in <code>retain</code>. * @throws NullPointerException if either parameter is null * @since 3.2 */ public static <C> Collection<C> retainAll(final Collection<C> collection, final Collection<?> retain) { return ListUtils.retainAll(collection, retain); } {noformat} We can notice the inefficiency by looking at the {{retainAll}} method in {{ListUtils}}. The {{retainAll}} method from {{ListUtils}} is implemented and documented as follows: {noformat} /** * Returns a List containing all the elements in <code>collection</code> * that are also in <code>retain</code>. The cardinality of an element <code>e</code> * in the returned list is the same as the cardinality of <code>e</code> * in <code>collection</code> unless <code>retain</code> does not contain <code>e</code>, in which * case the cardinality is zero. This method is useful if you do not wish to modify * the collection <code>c</code> and thus cannot call <code>collection.retainAll(retain);</code>. * <p> * This implementation iterates over <code>collection</code>, checking each element in * turn to see if it's contained in <code>retain</code>. If it's contained, it's added * to the returned list. As a consequence, it is advised to use a collection type for * <code>retain</code> that provides a fast (e.g. O(1)) implementation of * {@link Collection#contains(Object)}. * * @param <E> the element type * @param collection the collection whose contents are the target of the #retailAll operation * @param retain the collection containing the elements to be retained in the returned collection * @return a <code>List</code> containing all the elements of <code>c</code> * that occur at least once in <code>retain</code>. * @throws NullPointerException if either parameter is null * @since 3.2 */ public static <E> List<E> retainAll(final Collection<E> collection, final Collection<?> retain) { final List<E> list = new ArrayList<E>(Math.min(collection.size(), retain.size())); for (final E obj : collection) { if (retain.contains(obj)) { list.add(obj); } } return list; } {noformat} In the case of {{ListUtils#retainAll}}, the inefficiency is properly documented. Perhaps the disclaimer about potential inefficiencies depending on the type of the parameter collection in ListUtils:retainAll should also be included in {{CollectionUtils#retainAll}}. |
Collections, documentaion, performance | 5 years, 10 weeks, 1 day ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i248x3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-595 | ListOrderedSet remove() |
Bug | Resolved | Major | Not A Bug | Unassigned | Maleven | Maleven | 25/Sep/16 21:08 | 24/May/17 09:52 | 24/May/17 09:52 | 4.1 | Set | 0 | 3 | Windows 10, Eclipse Neon Release (4.6.0) | Hello Apache, I have a class which overrides equals() and hashCode(). I create a ListOrderedSet<MyClass> mySet= new ListOrderedSet<MyClass>(), and add objects to it: mySet.add(obj1); etc. Each object is initialized in the constructor with two properties first. The other properties are set afterwards, when they are already contained in the ListOrderedSet. After I change/add some properties, then if I do mySet.contains(obj1), false is returned. I read about that when a hashmap is created with the objects inside and then changing the objects inside it does not change the hasmap's internal hashcode for the objects or something like that. These properties are found in the equals and hashcode. (When not there is no issue.). The following happens. If I still want to remove an object which was changed afterwards, in the method: public E remove(final int index), inside public E remove(final int index) false is returned. But the object is still removed and in the debugger the following can be seen: DEBUG Info: this.collections.map.size == 5 (internal HashMap) this.collections.setOrder.size == 4. (internal ArrayList) Afterwards if I print the list with the overrided toString() method IndexOutOfBoundsException is thrown when getting the size of mySet via mySet.size(), but not when I use an iterator to count the objects in the set. {code:java} public int getSize() { OrderedIterator it = mySet.iterator(); int i = 0; while(it.hasNext()){ it.next(); i++; } //if i return i then the items are 4, when returning memorySet.size(), the items are 5. // return i; return mySet.size(); } @Override public String toString() { String toReturn = "\n"; for (int i = 0; i < getSize(); i++) { toReturn = toReturn + mySet.get(i) + "\n"; } return toReturn; } {code} So my question is: is this a bug or is it because of my changing/updating the objects in the list, and why if it returns false when removing it got deleted anyway? Should it not got deleted to start with? Thank you for your effort. P.S. I am a self taught programmer. It's my first time sending a bug issue, maybe it's a bit long or I did not send with it other information I should have. |
2 years, 42 weeks, 6 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i34267: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-584 | Deserializing an AbstractHashedMap expands the hash table exponentially |
Bug | Closed | Major | Invalid | Unassigned | Diogo Sousa | Diogo Sousa | 14/Dec/15 18:08 | 14/Dec/15 22:49 | 14/Dec/15 18:51 | 4.1 | 0 | 1 | When deserializing an {{AbstractHashedMap}} the size of the hashtable will be doubled at each element inserted because {{threshold}} = 0, so this {code} protected void checkCapacity() { if(this.size >= this.threshold) { int newCapacity = this.data.length * 2; if(newCapacity <= 1073741824) { this.ensureCapacity(newCapacity); } } } {code} will always expand the hashtable. |
4 years, 14 weeks, 1 day ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i2pvan: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-586 | PatriciaTrie prefixMap clear throws NullPointerException |
Bug | Closed | Major | Fixed | Unassigned | Shailender Bathula | Shailender Bathula | 12/Apr/16 21:59 | 18/Jul/17 18:56 | 04/Aug/16 17:33 | 4.1 | 0 | 4 | Clearing all entries of a prefixMap returned by PatriciaTrie using the {{clear}} method throws a NullPointerException. The workaround of removing each entry using the {{remove}} method seems to work. Here are the test cases for the bug and the workaround: {code:java} public class PatriciaTrieTest { private Trie<String, Integer> trie; @Before public void setUp() { trie = new PatriciaTrie<Integer>(); trie.put("Anna", 1); trie.put("Anael", 2); trie.put("Analu", 3); trie.put("Andreas", 4); trie.put("Andrea", 5); trie.put("Andres", 6); trie.put("Anatole", 7); } @Test public void testPrefixMapClear() { SortedMap<String, Integer> prefixMap = trie.prefixMap("And"); assertEquals(new HashSet<>(Arrays.asList("Andrea", "Andreas", "Andres")), prefixMap.keySet()); assertEquals(Arrays.asList(5, 4, 6), new ArrayList<>(prefixMap.values())); prefixMap.clear(); assertTrue(prefixMap.keySet().isEmpty()); assertTrue(prefixMap.values().isEmpty()); assertEquals(new HashSet<>(Arrays.asList("Anael", "Analu", "Anatole", "Anna")), trie.keySet()); assertEquals(Arrays.asList(2, 3, 7, 1), new ArrayList<>(trie.values())); } @Test public void testPrefixMapClearUsingRemove() { SortedMap<String, Integer> prefixMap = trie.prefixMap("And"); assertEquals(new HashSet<>(Arrays.asList("Andrea", "Andreas", "Andres")), prefixMap.keySet()); assertEquals(Arrays.asList(5, 4, 6), new ArrayList<>(prefixMap.values())); Set<String> keys = new HashSet<String>(prefixMap.keySet()); for (final String key : keys) { prefixMap.remove(key); } assertTrue(prefixMap.keySet().isEmpty()); assertTrue(prefixMap.values().isEmpty()); assertEquals(new HashSet<>(Arrays.asList("Anael", "Analu", "Anatole", "Anna")), trie.keySet()); assertEquals(Arrays.asList(2, 3, 7, 1), new ArrayList<>(trie.values())); } } {code} The stacktrace of the NullPointerException thrown by the {{testPrefixMapClear}} test case is: {noformat} java.lang.NullPointerException at org.apache.commons.collections4.trie.AbstractPatriciaTrie$PrefixRangeEntrySet$EntryIterator.remove(AbstractPatriciaTrie.java:2370) at java.util.AbstractCollection.clear(AbstractCollection.java:432) at java.util.AbstractMap.clear(AbstractMap.java:288) at PatriciaTrieTest.testPrefixMapClear(PatriciaTrieTest.java:39) {noformat} |
2 years, 35 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i2w0vz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-710 | NullPointerExceptions in CompositeCollection, CompositeSet, and CompositeMap |
Bug | Resolved | Major | Fixed | Unassigned | Yu Shi | Yu Shi | 29/Jan/19 22:00 | 09/Feb/19 23:01 | 09/Feb/19 23:01 | 4.2 | 4.4 | Collection, Map, Set | 0 | 1 | 3600 | 3600 | 0% | Windows 10
Eclipse IDE for Java Developers Version: 2018-09 (4.9.0) |
If we first add a null element into CompositeCollection by CompositeCollection.addComposited(nullElement), projects will crash and throw java.lang.NullPointerException when we call CompositeCollection.size().
For example, we have following code: ArrayList<String> nullList = null; CompositeCollection<String> cc = new CompositeCollection<String>(list); cc.addComposited(nullList); System.out.println(cc.size()); We will get: {{Exception in thread "main" java.lang.NullPointerException}} at org.apache.commons.collections4.collection.CompositeCollection.size(CompositeCollection.java:103) Because in CompositeCollection.size(), it iterate all items in the Collection, call item.size() and sum up their size. If the item point to null, the program will crash. This bug also exists in other methods of CompositeCollection. Moreover, CompositeSet and CompositeMap have the same bug. |
0% | 0% | 3600 | 3600 | nullpointerexception | 1 year, 5 weeks, 3 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|yi0gfk: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-695 | PatriciaTrie.subMap() does not return the expected outcome |
Bug | Resolved | Major | Invalid | Unassigned | Konrad Windszus | Konrad Windszus | 13/Sep/18 17:29 | 09/Oct/18 10:05 | 09/Oct/18 10:05 | 4.2 | 0 | 1 | I use a {{PatriciaTrie}} to basically retrieve the entry whose key is the longest prefix of a requested key.
Now I do have a simple trie with only two entries: # {{"/":<somevalue>}} # {{"/libs/cq/flow/widgets":<someothervalue>"}} If I call {{subMap("/", "/libs/cq/gui/components/authoring/dialog/"}} I would expect to only get back a map containing only entry 1. Instead I get back both entries. This happens primarily with those two specific keys. According to the javadoc of {{PatriciaTrie}} {quote} The Trie can return operations in lexicographical order using the 'prefixMap', 'submap', or 'iterator' methods. {quote} (https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/trie/PatriciaTrie.html) therefore I assumed that according to the lexicographical order only the "/" entry should be contained in here. Is this a bug or am I misinterpreting the Javadoc? |
1 year, 23 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i3y2gn: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-689 | Link to Javadoc API broken |
Bug | Closed | Minor | Fixed | Unassigned | Richard Walker | Richard Walker | 17/Jul/18 06:51 | 18/Jul/18 23:53 | 17/Jul/18 16:08 | 4.2 | 4.3 | Collection | 0 | 1 | On the front page [https://commons.apache.org/proper/commons-collections/] in the Documentation section, the link to the Javadoc API for "The current release 4.2" is broken. | 1 year, 34 weeks, 6 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i3vyo7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-593 | Compilation errors (generics) with JDK9 |
Bug | Closed | Major | Not A Problem | Unassigned | Vincent Privat | Vincent Privat | 03/Jul/16 18:55 | 28/Mar/17 22:54 | 28/Mar/17 22:54 | 4.x | 0 | 3 | Java 9b125 | Current codebase does not compile with JDK9 (build 125): 28 errors below. I am not sure if this is a bug of JDK9 of a stricter compilation rule with generics. [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/BagUtils.java:98: error: incompatible types: Bag<CAP#1> cannot be converted to Bag<E> [javac] return UnmodifiableBag.unmodifiableBag(bag); [javac] ^ [javac] where E is a type-variable: [javac] E extends Object declared in method <E>unmodifiableBag(Bag<? extends E>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends E from capture of ? extends E [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/CollectionUtils.java:795: error: incompatible types: Collection<CAP#1> cannot be converted to Collection<C> [javac] final Collection<C> resultCollection = collect(collection, transformer); [javac] ^ [javac] where C is a type-variable: [javac] C extends Object declared in method <C>transform(Collection<C>,Transformer<? super C,? extends C>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends C from capture of ? extends C [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/CollectionUtils.java:1835: error: incompatible types: Collection<CAP#1> cannot be converted to Collection<C> [javac] return UnmodifiableCollection.unmodifiableCollection(collection); [javac] ^ [javac] where C is a type-variable: [javac] C extends Object declared in method <C>unmodifiableCollection(Collection<? extends C>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends C from capture of ? extends C [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/FluentIterable.java:311: error: incompatible types: FluentIterable<CAP#1> cannot be converted to FluentIterable<O> [javac] return of(IterableUtils.transformedIterable(iterable, transformer)); [javac] ^ [javac] where O,E are type-variables: [javac] O extends Object declared in method <O>transform(Transformer<? super E,? extends O>) [javac] E extends Object declared in class FluentIterable [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends O from capture of ? extends O [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IterableUtils.java:429: error: incompatible types: Iterator<CAP#1> cannot be converted to Iterator<O> [javac] return IteratorUtils.transformedIterator(iterable.iterator(), transformer); [javac] ^ [javac] where O,I are type-variables: [javac] O extends Object declared in method <I,O>transformedIterable(Iterable<I>,Transformer<? super I,? extends O>) [javac] I extends Object declared in method <I,O>transformedIterable(Iterable<I>,Transformer<? super I,? extends O>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends O from capture of ? extends O [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IterableUtils.java:833: error: no suitable method found for partition(Iterable<CAP#1>,Factory<List<O#1>>,Predicate<? super O#1>[]) [javac] return partition(iterable, factory, predicates); [javac] ^ [javac] method IterableUtils.<O#1>partition(Iterable<? extends O#1>,Predicate<? super O#1>) is not applicable [javac] (cannot infer type-variable(s) O#1 [javac] (actual and formal argument lists differ in length)) [javac] method IterableUtils.<O#2>partition(Iterable<? extends O#2>,Predicate<? super O#2>...) is not applicable [javac] (cannot infer type-variable(s) O#2 [javac] (varargs mismatch; Factory<List<O#1>> cannot be converted to Predicate<? super O#2>)) [javac] method IterableUtils.<O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...) is not applicable [javac] (cannot infer type-variable(s) O#3,R [javac] (varargs mismatch; Predicate<? super O#1>[] cannot be converted to Predicate<? super O#3>)) [javac] where O#1,O#2,O#3,R are type-variables: [javac] O#1 extends Object declared in method <O#1>partition(Iterable<? extends O#1>,Predicate<? super O#1>) [javac] O#2 extends Object declared in method <O#2>partition(Iterable<? extends O#2>,Predicate<? super O#2>...) [javac] O#3 extends Object declared in method <O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...) [javac] R extends Collection<O#3> declared in method <O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends O#1 from capture of ? extends O#1 [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IterableUtils.java:873: error: no suitable method found for partition(Iterable<CAP#1>,Factory<List<O#1>>,Predicate<? super O#1>[]) [javac] return partition(iterable, factory, predicates); [javac] ^ [javac] method IterableUtils.<O#2>partition(Iterable<? extends O#2>,Predicate<? super O#2>) is not applicable [javac] (cannot infer type-variable(s) O#2 [javac] (actual and formal argument lists differ in length)) [javac] method IterableUtils.<O#1>partition(Iterable<? extends O#1>,Predicate<? super O#1>...) is not applicable [javac] (cannot infer type-variable(s) O#1 [javac] (varargs mismatch; Factory<List<O#1>> cannot be converted to Predicate<? super O#1>)) [javac] method IterableUtils.<O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...) is not applicable [javac] (cannot infer type-variable(s) O#3,R [javac] (varargs mismatch; Predicate<? super O#1>[] cannot be converted to Predicate<? super O#3>)) [javac] where O#1,O#2,O#3,R are type-variables: [javac] O#1 extends Object declared in method <O#1>partition(Iterable<? extends O#1>,Predicate<? super O#1>...) [javac] O#2 extends Object declared in method <O#2>partition(Iterable<? extends O#2>,Predicate<? super O#2>) [javac] O#3 extends Object declared in method <O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...) [javac] R extends Collection<O#3> declared in method <O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends O#1 from capture of ? extends O#1 [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IteratorUtils.java:438: error: incompatible types: BoundedIterator<CAP#1> cannot be converted to BoundedIterator<E> [javac] return boundedIterator(iterator, 0, max); [javac] ^ [javac] where E is a type-variable: [javac] E extends Object declared in method <E>boundedIterator(Iterator<? extends E>,long) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends E from capture of ? extends E [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IteratorUtils.java:862: error: incompatible types: PeekingIterator<CAP#1> cannot be converted to Iterator<E> [javac] return PeekingIterator.peekingIterator(iterator); [javac] ^ [javac] where E is a type-variable: [javac] E extends Object declared in method <E>peekingIterator(Iterator<? extends E>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends E from capture of ? extends E [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IteratorUtils.java:878: error: incompatible types: PushbackIterator<CAP#1> cannot be converted to Iterator<E> [javac] return PushbackIterator.pushbackIterator(iterator); [javac] ^ [javac] where E is a type-variable: [javac] E extends Object declared in method <E>pushbackIterator(Iterator<? extends E>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends E from capture of ? extends E [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IteratorUtils.java:1086: error: incompatible types: List<CAP#1> cannot be converted to List<E> [javac] final List<E> list = toList(iterator, 100); [javac] ^ [javac] where E is a type-variable: [javac] E extends Object declared in method <E>toArray(Iterator<? extends E>,Class<E>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends E from capture of ? extends E [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IteratorUtils.java:1104: error: incompatible types: List<CAP#1> cannot be converted to List<E> [javac] return toList(iterator, 10); [javac] ^ [javac] where E is a type-variable: [javac] E extends Object declared in method <E>toList(Iterator<? extends E>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends E from capture of ? extends E [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/ListUtils.java:394: error: incompatible types: List<CAP#1> cannot be converted to List<E> [javac] return UnmodifiableList.unmodifiableList(list); [javac] ^ [javac] where E is a type-variable: [javac] E extends Object declared in method <E>unmodifiableList(List<? extends E>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends E from capture of ? extends E [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/MapUtils.java:1272: error: incompatible types: Map<CAP#1,CAP#2> cannot be converted to Map<K,V> [javac] return UnmodifiableMap.unmodifiableMap(map); [javac] ^ [javac] where K,V are type-variables: [javac] K extends Object declared in method <K,V>unmodifiableMap(Map<? extends K,? extends V>) [javac] V extends Object declared in method <K,V>unmodifiableMap(Map<? extends K,? extends V>) [javac] where CAP#1,CAP#2 are fresh type-variables: [javac] CAP#1 extends K from capture of ? extends K [javac] CAP#2 extends V from capture of ? extends V [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/MapUtils.java:1537: error: incompatible types: SortedMap<K,CAP#1> cannot be converted to SortedMap<K,V> [javac] return UnmodifiableSortedMap.unmodifiableSortedMap(map); [javac] ^ [javac] where K,V are type-variables: [javac] K extends Object declared in method <K,V>unmodifiableSortedMap(SortedMap<K,? extends V>) [javac] V extends Object declared in method <K,V>unmodifiableSortedMap(SortedMap<K,? extends V>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends V from capture of ? extends V [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/MultiSetUtils.java:85: error: incompatible types: MultiSet<CAP#1> cannot be converted to MultiSet<E> [javac] return UnmodifiableMultiSet.unmodifiableMultiSet(multiset); [javac] ^ [javac] where E is a type-variable: [javac] E extends Object declared in method <E>unmodifiableMultiSet(MultiSet<? extends E>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends E from capture of ? extends E [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/PredicateUtils.java:537: error: incompatible types: Predicate<CAP#1> cannot be converted to Predicate<T> [javac] return TransformedPredicate.transformedPredicate(transformer, predicate); [javac] ^ [javac] where T is a type-variable: [javac] T extends Object declared in method <T>transformedPredicate(Transformer<? super T,? extends T>,Predicate<? super T>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends T from capture of ? extends T [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/QueueUtils.java:56: error: incompatible types: Queue<CAP#1> cannot be converted to Queue<E> [javac] return UnmodifiableQueue.unmodifiableQueue(queue); [javac] ^ [javac] where E is a type-variable: [javac] E extends Object declared in method <E>unmodifiableQueue(Queue<? extends E>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends E from capture of ? extends E [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/SetUtils.java:225: error: incompatible types: Set<CAP#1> cannot be converted to Set<E> [javac] return UnmodifiableSet.unmodifiableSet(set); [javac] ^ [javac] where E is a type-variable: [javac] E extends Object declared in method <E>unmodifiableSet(Set<? extends E>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends E from capture of ? extends E [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/SetUtils.java:505: error: incompatible types: Iterator<CAP#1> cannot be converted to Iterator<E> [javac] return IteratorUtils.filteredIterator(a.iterator(), notContainedInB); [javac] ^ [javac] where E is a type-variable: [javac] E extends Object declared in method <E>difference(Set<? extends E>,Set<? extends E>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends E from capture of ? extends E [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/SetUtils.java:543: error: incompatible types: Iterator<CAP#1> cannot be converted to Iterator<E> [javac] return IteratorUtils.filteredIterator(a.iterator(), containedInB); [javac] ^ [javac] where E is a type-variable: [javac] E extends Object declared in method <E>intersection(Set<? extends E>,Set<? extends E>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends E from capture of ? extends E [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/TransformerUtils.java:187: error: incompatible types: no instance(s) of type variable(s) I#1 exist so that Transformer<I#1,CAP#1> conforms to Transformer<I#2,O#2> [javac] return FactoryTransformer.factoryTransformer(factory); [javac] ^ [javac] where I#1,O#1,O#2,I#2 are type-variables: [javac] I#1 extends Object declared in method <I#1,O#1>factoryTransformer(Factory<? extends O#1>) [javac] O#1 extends Object declared in method <I#1,O#1>factoryTransformer(Factory<? extends O#1>) [javac] O#2 extends Object declared in method <I#2,O#2>asTransformer(Factory<? extends O#2>) [javac] I#2 extends Object declared in method <I#2,O#2>asTransformer(Factory<? extends O#2>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends O#2 from capture of ? extends O#2 [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/TransformerUtils.java:235: error: incompatible types: Transformer<CAP#1,CAP#1> cannot be converted to Transformer<T,T> [javac] return IfTransformer.ifTransformer(predicate, trueTransformer); [javac] ^ [javac] where T is a type-variable: [javac] T extends Object declared in method <T>ifTransformer(Predicate<? super T>,Transformer<? super T,? extends T>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends T from capture of ? extends T [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/TransformerUtils.java:428: error: incompatible types: no instance(s) of type variable(s) I#1 exist so that Transformer<I#1,CAP#1> conforms to Transformer<I#2,O#2> [javac] return MapTransformer.mapTransformer(map); [javac] ^ [javac] where I#1,O#1,O#2,I#2 are type-variables: [javac] I#1 extends Object declared in method <I#1,O#1>mapTransformer(Map<? super I#1,? extends O#1>) [javac] O#1 extends Object declared in method <I#1,O#1>mapTransformer(Map<? super I#1,? extends O#1>) [javac] O#2 extends Object declared in method <I#2,O#2>mapTransformer(Map<? super I#2,? extends O#2>) [javac] I#2 extends Object declared in method <I#2,O#2>mapTransformer(Map<? super I#2,? extends O#2>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends O#2 from capture of ? extends O#2 [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/TrieUtils.java:46: error: incompatible types: Trie<K,CAP#1> cannot be converted to Trie<K,V> [javac] return UnmodifiableTrie.unmodifiableTrie(trie); [javac] ^ [javac] where K,V are type-variables: [javac] K extends Object declared in method <K,V>unmodifiableTrie(Trie<K,? extends V>) [javac] V extends Object declared in method <K,V>unmodifiableTrie(Trie<K,? extends V>) [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends V from capture of ? extends V [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/iterators/IteratorIterable.java:118: error: incompatible types: Iterator<CAP#1> cannot be converted to Iterator<E> [javac] this.typeSafeIterator = createTypesafeIterator(this.iterator); [javac] ^ [javac] where E is a type-variable: [javac] E extends Object declared in class IteratorIterable [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends E from capture of ? extends E [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/multimap/TransformedMultiValuedMap.java:162: error: incompatible types: FluentIterable<CAP#1> cannot be converted to Iterable<V> [javac] final Iterable<V> transformedValues = FluentIterable.of(values).transform(valueTransformer); [javac] ^ [javac] where V is a type-variable: [javac] V extends Object declared in class TransformedMultiValuedMap [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends V from capture of ? extends V [javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/imaging/util/Debug.java:125: error: incompatible types: ArrayList<CAP#1> cannot be converted to List<Object> [javac] final List<Object> keys = new ArrayList<>(map.keySet()); [javac] ^ [javac] where CAP#1 is a fresh type-variable: [javac] CAP#1 extends Object from capture of ? [javac] 28 errors [javac] 1 warning |
generics, jdk9, josm-found | 3 years, 10 weeks, 2 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i30hcn: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-470 | TransformedMap class exists in two packages |
Bug | Closed | Major | Fixed | Unassigned | Sebb | Sebb | 14/May/13 15:15 | 09/Nov/14 14:31 | 11/Jun/13 20:29 | 4.x | 4.0-alpha1, 4.0 | 0 | 0 | It's very confusing to have two different TransformedMap classes in different packages: map, splitmap. Indeed the Test class has to take special care with the serialised file name to avoid a clash. Since we can break binary compat in v4, now is the time to rename one of the classes. Perhaps rename as follows: splitmap/TransformedMap => splitmap/TransformedGetPutMap |
6 years, 41 weeks ago | 327876 | No Perforce job exists for this issue. | 0 | 328220 | 0|i1kkkf: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-519 | private constructors in utility classes break existing code |
Bug | Closed | Major | Won't Fix | Unassigned | Radoslav Paskalev | Radoslav Paskalev | 22/Apr/14 10:05 | 27/Nov/15 21:47 | 02/May/14 09:00 | 4.x | 1 | 4 | COLLECTIONS-276 | Hello, In collections version 4.x all utility classes (example ListUtils, MapUtils, PredicateUtils....) have private constructors. I consider this to be a serious bug, as it breaks any possibility the classes to be extended by the users. The javadoc says that constructors are private in order to prevent class instantiation but this object instantiation is not really problem and i think it is more important to allow classes to be extended. The possibility to extend utility classes was one of the major selling points of commons.lang and commons.collections projects. In the latest commons.lang project the utility classes still have public constructors. Best Regards |
5 years, 46 weeks, 4 days ago | 388053 | No Perforce job exists for this issue. | 0 | 388311 | 0|i1uui7: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-372 | ComparatorUtils.transformedComparator wrongly typed (generics) |
Bug | Closed | Minor | Fixed | Unassigned | HaveNone | HaveNone | 18/Mar/11 12:45 | 09/Nov/14 14:31 | 06/Mar/13 19:52 | 4.x | 4.0-alpha1, 4.0 | Comparator | 1 | 0 | COLLECTIONS-333 | n/a | ComparatorUtils.transformedComparator is currently typed as follows : {{public static <I,O> Comparator<O> transformedComparator(Comparator<I> comparator, Transformer<I, O> transformer)}} It should be typed as follows so that is can be used without removing generics typing: {{public static <I,O> Comparator<I> transformedComparator(Comparator<O> comparator, Transformer<I, O> transformer)}} Here is a unit test for it : Transformer<Integer, String> itosTransformer = TransformerUtils.stringValueTransformer(); Comparator<Integer> c = new Comparator<Integer>() { @Override public int compare(Integer o1, Integer o2) { return o1.compareTo(o2); } }; Comparator<String> stringComparator = ComparatorUtils.transformedComparator(c, itosTransformer); stringComparator.compare("string1", "string2"); |
patch | 7 years, 2 weeks, 6 days ago | 18631 | No Perforce job exists for this issue. | 0 | 90356 | 0|i0ftdb: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-447 | TreeListIterator can return incorrect results after remove() is called |
Bug | Closed | Major | Fixed | Unassigned | Jeffrey Barnes | Jeffrey Barnes | 03/Mar/13 03:24 | 09/Nov/15 20:53 | 04/Mar/13 20:20 | Nightly Builds | 3.2.2, 4.0-alpha1, 4.0 | Collection | 0 | 1 | COLLECTIONS-433 | Windows 7, jdk1.5.0_22 | {{TreeList.TreeListIterator}} can get in a bad state when {{remove()}} is called, causing it to subsequently return incorrect results. This is because {{TreeListIterator}} caches an {{AVLNode}} reference in its field {{next}}, and this node reference may become stale when {{remove()}} is called (it may contain a reference to a node that no longer exists in the tree). I will attach two patches: {{testcase.patch}} will contain a test case illustrating the bug, and {{fix.patch}} will contain a fix. (To fix the bug, I simply clear the cached {{next}} value in {{TreeListIterator.remove}}.) This was originally reported in a comment to COLLECTIONS-433; I am creating a separate issue for this at Thomas Neidhart's suggestion. |
patch, test | 7 years, 3 weeks, 1 day ago | 315498 | No Perforce job exists for this issue. | 2 | 315842 | 0|i1ifxz: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-414 | Collections does not compile with openjdk 1.6.0_24 |
Bug | Closed | Major | Fixed | Unassigned | Thomas Neidhart | Thomas Neidhart | 23/Jun/12 12:31 | 09/Nov/14 14:31 | 15/Jul/12 11:19 | Nightly Builds | 4.0-alpha1, 4.0 | 0 | 1 | There are several classes for which generic type inference does not work when using the openjdk 1.6.0_24 compiler: {noformat} [ERROR] /home/tn/workspace/apache/commons-collections/src/main/java/org/apache/commons/collections/functors/OnePredicate.java:[66,38] invalid inferred types for T; actual arguments do not conforms to inferred formal arguments [ERROR] required: org.apache.commons.collections.Predicate<? super java.lang.Object>[] [ERROR] found: org.apache.commons.collections.Predicate<? super T>[] {noformat} This is mainly due to re-using a method argument that is restricted by Predicate<? super T> to assign methods results of type Predicate<T>. The eclipse compiler does not report an error in these cases. |
7 years, 39 weeks, 3 days ago | 292944 | No Perforce job exists for this issue. | 0 | 164346 | 0|i0shpj: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-601 | commons-collections unit tests broken in Java 8 |
Bug | Resolved | Major | Cannot Reproduce | Unassigned | Allon Mureinik | Allon Mureinik | 20/Mar/17 10:38 | 25/May/17 11:07 | 24/May/17 08:25 | Nightly Builds | 0 | 2 | Maven 3.3.9, Java 1.8.0-121-1.b14, Fedora 25 - full details in attached logs | Building the upstream trunk (currently, patch 30b2aca) fails the unit tests in Java 8, but passes in Java 7 on the same machine. Attached logs with env details an errors of a successful Java 7 build and an unsuccessful Java 8 build | test | 2 years, 42 weeks, 5 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 2 | 9223372036854775807 | 0|i3ciav: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-255 | Unused variable in TreeBidiMap.java |
Bug | Closed | Trivial | Fixed | Unassigned | Henri Yandell | Henri Yandell | 08/Jun/07 00:32 | 09/Nov/14 14:31 | 28/Feb/13 19:55 | Nightly Builds | 4.0-alpha1, 4.0 | BidiMap | 0 | 0 | Twice in TreeBidiMap there is an entrySet variable that is not used. Rather the entrySet() method returns a new TreeView every time. We should either: a) Delete the variable. b) Use the variable and always return the same TreeView. I'm thinking a). [Found via http://opensource.fortifysoftware.com/ ] |
10 years, 13 weeks ago | 18745 | No Perforce job exists for this issue. | 1 | 164468 | 0|i0sign: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-135 | [PATCH] SwitchTransformer doc/impl inconsistent |
Bug | Closed | Trivial | Fixed | Unassigned | Matt Benson | Matt Benson | 05/Apr/06 05:38 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
TransformerUtils says that a null defaultTransformer will return null; this is consistent with the switchTransformer tests under TestTransformerUtils. However, the SwitchTransformer constructor's javadoc says that a null defaultTransformer means nop, which is incorrect. Not that it matters, but NOP would have been more intuitive IMHO, but what's done is done and passing NOPTransformer.INSTANCE or TransformerUtils.nopTransformer() is no big deal. |
13 years, 51 weeks ago | 18863 | No Perforce job exists for this issue. | 1 | 39207 | 164573 | 0|i0sj3z: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-117 | [collections][PATCH] correct misspelling in RELEASE-NOTES.html |
Bug | Closed | Trivial | Fixed | Unassigned | Matt Benson | Matt Benson | 06/Jan/06 02:45 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
s/COMPATABILITY/COMPATIBILITY/ | 14 years, 12 weeks, 3 days ago | 18881 | No Perforce job exists for this issue. | 1 | 38140 | 164591 | 0|i0sj7z: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-114 | [collections] Build Warnings when building under JDK 1.5 |
Bug | Closed | Major | Fixed | Unassigned | Will Pugh | Will Pugh | 23/Jun/05 03:36 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
When I build under JDK 1.5 on MacOSX, I get a bunch of warnings. Almost all of them are a result of some APIs moving over to using varargs. Here is an example of some of the warnings. The fixes in just about all cases was to cast a null to either (Method[]) or (Object[]). in one place a temporary array new String[] { ... } had to be changed to new Object[] { ... } [javac] Compiling 271 source files to /Users/willpugh/projects/beanutils2/collections2/collections/target/classes /Users/willpugh/projects/beanutils2/collections2/collections/src/java/org/apache/commons/collections/functors/PrototypeFactory.java:62: warning: non-varargs call of varargs method with inexact argument type for last parameter; cast to java.lang.Class for a varargs call cast to java.lang.Class[] for a non-varargs call and to suppress this warning Method method = prototype.getClass().getMethod("clone", null); ^ /Users/willpugh/projects/beanutils2/collections2/collections/src/java/org/apache/commons/collections/functors/PrototypeFactory.java:119: warning: non-varargs call of varargs method with inexact argument type for last parameter; cast to java.lang.Class for a varargs call cast to java.lang.Class[] for a non-varargs call and to suppress this warning iCloneMethod = iPrototype.getClass().getMethod("clone", null); . . . |
14 years, 40 weeks, 3 days ago | 18884 | No Perforce job exists for this issue. | 1 | 35474 | 164594 | 0|i0sj8n: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-68 | [collections] Concurrent modification in FastArrayList |
Bug | Closed | Major | Fixed | Unassigned | Guilhem Lavaux | Guilhem Lavaux | 01/May/05 03:11 | 15/Mar/08 21:35 | 14/Jul/06 12:04 | Nightly Builds | 1 | 0 | Operating System: All Platform: All |
I confirm a bug highlighted by GNU Classpath internal checkings concerning FastArrayList. It uses two different paths for modifying a list and accessing it in FastArrayList$ListIter.remove. On 2005-04-30 SVN snapshot the line which causes problem is at org.apache.commons.collections.FastArrayList$ListIter.remove (FastArrayList.java:1308) because previousIndex() is used on an iterator which has not followed the modification introduced by a call to List.remove. This bug is not detected by Sun's JDK. |
13 years, 37 weeks, 4 days ago | 18930 | No Perforce job exists for this issue. | 0 | 34690 | 164640 | 0|i0sjiv: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-56 | NoSuchElementException in ReferenceMap views |
Bug | Closed | Major | Fixed | Unassigned | Joe Raysa | Joe Raysa | 16/Dec/03 08:57 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | Nightly Builds | 0 | 0 | Operating System: All Platform: PC |
The keySet() and values() views for the org.apache.commons.collections.map.ReferenceMap class will throw a NoSuchElementException in their toArray(Object[]) methods if any keys or values have been reclaimed by the garbage collector and purge() has not been invoked. The toArray(Object[]) implementation inherited from java.util.AbstractCollection uses size()-based iteration rather than hasNext()- based iteration. This is inappropriate because the size of the map can change during iteration. The problem is exacerbated by the fact that neither the KeySet nor Values classes purge stale elements from the list in their size() methods. The attached test case reliably reproduces this exception with Sun's 1.3.1_07 and 1.4.2 Win2K Hotspot VMs. The attached diff is a proposed fix for this issue. |
16 years, 14 weeks, 1 day ago | 18942 | No Perforce job exists for this issue. | 2 | 25551 | 164652 | 0|i0sjlj: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-97 | [collections][PATCH] JavaDoc fixes for iterators |
Bug | Closed | Minor | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 11/Sep/03 04:50 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
The attached patch fixes three typos in ComparatorChain, FixedOrderComparator and TransformingComparator. |
16 years, 28 weeks, 6 days ago | 18901 | No Perforce job exists for this issue. | 1 | 23087 | 164611 | 0|i0sjcf: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-25 | [collections][PATCH] OutOfMemoryError test case for MapUtils.verbosePrint. |
Bug | Closed | Major | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 10/Sep/03 04:02 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
The attached patch adds a test case to TestMapUtils that demonstrates infinite recursion in MapUtils.verbosePrint. |
16 years, 28 weeks, 5 days ago | 18973 | No Perforce job exists for this issue. | 2 | 23041 | 164683 | 0|i0sjsf: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-136 | [collections][PATCH] CollectionUtils.getFreq optimization |
Bug | Closed | Major | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 09/Sep/03 03:59 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
The attached patch improves the performance of CollectionUtils.getFreq(Object, Map) by using a test in place of a thrown exception. The effect of the change was measured with the class below. These are the times for the Sun JDK 1.4.1_03 on Red Hat Linux 8.0 pre-optimization: 122534 post-optimization: 104637 The patch reduced the time to run the test to 85% of the original. The also patch removes a catch of NoSuchElementException which, as far as I can tell, was unnecessary in the original code. This is the test class: import org.apache.commons.collections.CollectionUtils ; import java.util.*; public class CollectionUtilsTest { Set a ; Set b ; Set c ; Collection cols [] ; long startMillis ; void init () { a = new HashSet () ; for ( int i = 1 ; i <= 10000 ; i++ ) { a.add ( new Integer ( i ) ) ; } b = new HashSet () ; for ( int i = 5001 ; i <= 15000 ; i++ ) { b.add ( new Integer ( i ) ) ; } c = new HashSet () ; for ( int i = 10001 ; i <= 20000 ; i++ ) { c.add ( new Integer ( i ) ) ; } cols = new Collection [] { a, b, c } ; startMillis = System.currentTimeMillis () ; } void run () { for ( int i = 0 ; i < 3 ; i++ ) { for ( int j = 0 ; j < 3 ; j++ ) { CollectionUtils.union ( cols [ i ], cols [ j ] ) ; CollectionUtils.intersection ( cols [ i ], cols [ j ] ) ; CollectionUtils.disjunction ( cols [ i ], cols [ j ] ) ; CollectionUtils.subtract ( cols [ i ], cols [ j ] ) ; } } } void report () { System.out.println ( "Elapsed millis: " + ( System.currentTimeMillis () - startMillis ) ) ; } public static void main ( String [] arg ) { CollectionUtilsTest t = new CollectionUtilsTest () ; t.init () ; t.run () ; t.report () ; } } |
16 years, 29 weeks, 6 days ago | 18862 | No Perforce job exists for this issue. | 1 | 23004 | 164572 | 0|i0sj3r: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-58 | [collections] [PATCH] patch to reduce object creation in CollectionUtils |
Bug | Closed | Minor | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 08/Sep/03 05:29 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
The attached patch reduces the number of Integer objects created when invoking CollectionUtils.getCardinalityMap(final Collection col). The number of Integers created is reduced by the count of unique objects within col. The patch does not change the basic algorithm so the simplicity of the method is not lost. The change was profiled with the class below. These are the absolute times for JDK 1.3.1_04 and 1.4.1_03 1.4 1.3 pre: 168267 153849 post: 164473 150866 and normalised to the pre version for each JDK 1.4 1.3 pre: 1.00 1.00 post: 0.98 0.98 so there was only a minor speed difference however the reduction in the number of created objects has a memory use advantage. It was surprising to see that JDK 1.4.1 was slower than 1.3.1, in this limited test. The binaries were compiled with JDK 1.4.1. This is the test class: import org.apache.commons.collections.CollectionUtils ; import java.util.*; public class CollectionUtilsTest { Set a ; Set b ; Set c ; Collection cols [] ; long startMillis ; void init () { a = new HashSet () ; for ( int i = 1 ; i <= 10000 ; i++ ) { a.add ( new Integer ( i ) ) ; } b = new HashSet () ; for ( int i = 5001 ; i <= 15000 ; i++ ) { b.add ( new Integer ( i ) ) ; } c = new HashSet () ; for ( int i = 1001 ; i <= 20000 ; i++ ) { c.add ( new Integer ( i ) ) ; } cols = new Collection [] { a, b, c } ; startMillis = System.currentTimeMillis () ; } void run () { for ( int i = 0 ; i < 3 ; i++ ) { for ( int j = 0 ; j < 3 ; j++ ) { CollectionUtils.union ( cols [ i ], cols [ j ] ) ; CollectionUtils.intersection ( cols [ i ], cols [ j ] ) ; CollectionUtils.disjunction ( cols [ i ], cols [ j ] ) ; CollectionUtils.subtract ( cols [ i ], cols [ j ] ) ; } } } void report () { System.out.println ( "Elapsed millis: " + ( System.currentTimeMillis () - startMillis ) ) ; } public static void main ( String [] arg ) { CollectionUtilsTest t = new CollectionUtilsTest () ; t.init () ; t.run () ; t.report () ; } } |
16 years, 29 weeks, 6 days ago | 18940 | No Perforce job exists for this issue. | 1 | 22973 | 164650 | 0|i0sjl3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-125 | [collections] [PATCH] MapUtils JavaDoc fixes |
Bug | Closed | Minor | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 08/Sep/03 04:35 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
The attached patch modifies some documentation tags and fixes the code example for MapUtils.lazySortedMap. |
16 years, 29 weeks, 6 days ago | 18873 | No Perforce job exists for this issue. | 1 | 22972 | 164583 | 0|i0sj67: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-90 | [collections][PATCH] JavaDoc simplification for CollectionUtils |
Bug | Closed | Major | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 07/Sep/03 08:40 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
The attached patch removes some extraneous @return and @throws tags and makes the effect of a null Predicate easier to understand for a couple of methods. |
16 years, 30 weeks, 2 days ago | 18908 | No Perforce job exists for this issue. | 1 | 22964 | 164618 | 0|i0sjdz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-112 | [collections] [PATCH] fixes some @author hrefs or removes the link markup |
Bug | Closed | Minor | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 07/Sep/03 06:43 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
The attached patches are mutually exclusive and either fix some hrefs in some @author tags which are missing 'mailto:' prefixes or (to match a recently applied collections patch) remove the link markup altogether. |
16 years, 30 weeks, 2 days ago | 18886 | No Perforce job exists for this issue. | 2 | 22962 | 164596 | 0|i0sj93: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-19 | [collections] 'acknowledgement' typos in licence headers |
Bug | Closed | Minor | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 31/Aug/03 08:58 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
The Apache Software License includes these typos in various files 'acknowlegement' in 54 files 'acknowledgment/acknowledgements' in 519 files |
16 years, 31 weeks, 2 days ago | 18979 | No Perforce job exists for this issue. | 0 | 22845 | 164689 | 0|i0sjtr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-119 | [collections] Misnamed method in FixedOrderComparator: getUnkownObjectBehavior |
Bug | Closed | Major | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 31/Aug/03 08:45 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
The method is probably meant to be getUnknownObjectBehavior() From the class: FixedOrderComparator { ... /** * Gets the behavior for comparing unknown objects. */ public int getUnkownObjectBehavior() { return unknownObjectBehavior; } ... } |
16 years, 31 weeks, 2 days ago | 18879 | No Perforce job exists for this issue. | 0 | 22844 | 164589 | 0|i0sj7j: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-47 | [collections] [PATCH] fixes 97 typos |
Bug | Closed | Minor | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 31/Aug/03 08:35 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
The attached patch fixes 97 typos in the version of collections from 03-August-31. | 16 years, 31 weeks, 1 day ago | 18951 | No Perforce job exists for this issue. | 1 | 22843 | 164661 | 0|i0sjnj: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-54 | [collections][PATCH] increase number of tests run from 2484 to 7429 |
Bug | Closed | Critical | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 14/Sep/03 04:29 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
The attached file patches build.xml to use 'TestAllPackages' instead of 'TestAll' for the value of 'test.entry'. This results in a greater number of tests being run. project.xml also uses 'TestAll' but there this patch does not fix that becuase I am not using maven. (I find this situation a bit odd because Stephen Colebourne mentioned that some bugs had been detected in o.a.c.collections.observed package a few days ago by some tests and as far as I can see those tests would not have run without this change. Is the use of ant deprecated or am I just not seeing something obvious or customary?) |
16 years, 28 weeks, 6 days ago | 18944 | No Perforce job exists for this issue. | 1 | 23155 | 164654 | 0|i0sjlz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-20 | [collections] TestObservedBag and TestObservedSet fail under Java 1.3.1 |
Bug | Closed | Major | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 17/Sep/03 03:05 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
With CVS HEAD of 2003-Sept-16 two unit tests fail under Java 1.3.1_04. $ java -version java version "1.3.1_04" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_04-b02) Java HotSpot(TM) Client VM (build 1.3.1_04-b02, mixed mode) The stack trace is: [java] There were 2 failures: [java] 1) testObservedSet(o.a.c.collections.observed.TestObservedBag) junit.framework.AssertionFailedError: expected same:<7> was not:<6> [java] at o.a.c.collections.observed.ObservedTestHelper.doTestRemoveIterated(ObservedTestHelper.java:933) [java] at o.a.c.collections.observed.ObservedTestHelper.bulkTestObservedCollection(ObservedTestHelper.java:156) [java] at o.a.c.collections.observed.ObservedTestHelper.bulkTestObservedBag(ObservedTestHelper.java:188) [java] at o.a.c.collections.observed.TestObservedBag.testObservedSet(TestObservedBag.java:98) [java] 2) testObservedSet(o.a.c.collections.observed.TestObservedSet) junit.framework.AssertionFailedError: expected same:<7> was not:<6> [java] at o.a.c.collections.observed.ObservedTestHelper.doTestRemoveIterated(ObservedTestHelper.java:933) [java] at o.a.c.collections.observed.ObservedTestHelper.bulkTestObservedCollection(ObservedTestHelper.java:156) [java] at o.a.c.collections.observed.ObservedTestHelper.bulkTestObservedSet(ObservedTestHelper.java:164) [java] at o.a.c.collections.observed.TestObservedSet.testObservedSet(TestObservedSet.java:106) [java] FAILURES!!! [java] Tests run: 7489, Failures: 2, Errors: 0 It doesn't matter whether it is compiled with 1.4.1 or 1.3.1 as summarized here: Run with: 1.3.1_04 1.4.1_03 Compiled with: 1.3.1_04 fail pass 1.4.1_03 fail pass |
16 years, 28 weeks, 3 days ago | 18978 | No Perforce job exists for this issue. | 0 | 23201 | 164688 | 0|i0sjtj: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-16 | ExtendedProperties never sets isInitialized |
Bug | Closed | Major | Fixed | Unassigned | Walt | Walt | 18/Jan/03 06:16 | 15/Mar/08 21:35 | 14/Jul/06 12:05 | Nightly Builds | 1 | 0 | Operating System: All Platform: All |
ExtendedProperties.isInitialized() is always false. The only code that sets it is in a private init() function that is never called. Some other apps (Torque) have depended on isInitialized being set to true after a load but apparently the Torque devs never realized it wasn't. I'll attach a patch to correct this. The patch removes the private, never used, init() function and sets isInitialized on either a load() or addProperty(). |
13 years, 37 weeks, 4 days ago | 18982 | No Perforce job exists for this issue. | 1 | 16225 | 164692 | 0|i0sjuf: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-1 | [collections] Collections Javadoc warnings with JDK 1.4.2 |
Bug | Closed | Major | Fixed | Unassigned | Eric Johnson | Eric Johnson | 09/Oct/03 00:57 | 18/Mar/20 02:33 | 14/Jul/06 05:48 | 14/Jul/06 05:48 | Nightly Builds | 3.0 | 0 | 0 | Operating System: All Platform: All |
Numerous javadoc warnings when doing "ant dist" target under JDK 1.4.2. Partial patch to follow |
14 years, 35 weeks, 5 days ago | 18997 | No Perforce job exists for this issue. | 4 | 23680 | 164707 | 0|i0sjxr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-126 | [patch] JDK 1.4.1 compil error / TestHashMap.java does not define makeEmptyMap() in org.apache.commons.collections.TestMap |
Bug | Closed | Major | Incomplete | Unassigned | Jari Aalto | Jari Aalto | 23/Jul/02 23:14 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | Nightly Builds | 0 | 0 | Operating System: All Platform: PC |
Environment: Win32 W2kSp2 / cygwin Win32 JDK 1.4.1 CVS ant CVS jakarta-commons There is problem with compiling. See attached patch, which I AM NOT SURE if it is correct solution. At least it builds without this error. - jari root@W2KPICASSO:/cygdrive/d/java/apache/cvs/jakarta-commons/collections$ ant.bat Buildfile: build.xml init: build-java: build-test: [javac] Compiling 62 source files to D:\java\apache\cvs\jakarta- commons\collections\dist\classes [javac] D:\java\apache\cvs\jakarta- commons\collections\src\test\org\apache\commons\collections\TestHashMap.java:74: org.apache.commons.collections.TestHashMap should be declared abstract; it does not define makeEmptyMap() in org.apache.commons.collections.TestMap [javac] public class TestHashMap extends TestMap [javac] ^ [javac] 1 error BUILD FAILED file:d:/java/apache/cvs/jakarta-commons/collections/build.xml:216: Compile failed; see the compiler error output for details. Total time: 20 seconds ========================================================================== root@W2KPICASSO:/cygdrive/d/java/apache/cvs/jakarta-commons/collections$ diff - u src/test/org/apache/commons/collections/TestHashMap.java.orig src/test/org/apache/commons/collections/TestHashMap.java --- src/test/org/apache/commons/collections/TestHashMap.java.orig 2001-07- 15 01:33:28.000000000 +0300 +++ src/test/org/apache/commons/collections/TestHashMap.java 2002-07-23 13:45:34.000000000 +0300 @@ -94,6 +94,11 @@ return (hm); } + public Map makeEmptyMap() + { + return makeMap(); + } + protected HashMap map = null; public void setUp() |
16 years, 41 weeks, 1 day ago | 18872 | No Perforce job exists for this issue. | 1 | 11092 | 164582 | 0|i0sj5z: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-41 | LazyCollections.lazyList.get(i) grows wrong |
Bug | Closed | Major | Fixed | Unassigned | Nikolaj Joergensen | Nikolaj Joergensen | 07/Aug/02 13:39 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
LazyCollections.lazyList.get(i) grows wrong when called with i == (size() -1). If the list has 3 elements and LazyCollections.lazyList.get(2) is called then size of the list will grow to size == 4 because within bounds check says: if(index < (this.listImpl.size()-1) { Should be: if(index < this.listImpl.size()) { |
17 years, 34 weeks ago | 18957 | No Perforce job exists for this issue. | 1 | 11522 | 164667 | 0|i0sjov: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-9 | [collections] ~20 Javadoc fixes and type cast clean ups. |
Bug | Closed | Major | Fixed | Unassigned | Gary D. Gregory | ggregory@seagullsw.com | 07/Jan/04 07:27 | 10/Mar/11 23:16 | 15/Mar/08 21:35 | Nightly Builds | 0 | 0 | Operating System: All Platform: All |
Please see patch file attached. | 16 years, 12 weeks, 4 days ago | 18989 | No Perforce job exists for this issue. | 1 | 25936 | 164699 | 0|i0sjvz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-78 | BinaryHeap.remove(Object) seems to break heap order |
Bug | Closed | Major | Fixed | Unassigned | Steve Phelps | Steve Phelps | 30/Dec/03 16:46 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | Nightly Builds | 0 | 0 | Operating System: Linux Platform: PC |
I am currently attempting to migrate from my own implementation of a BinaryHeap to the implementation in org.apache.commons.collections.BinaryHeap. I have some existing unit tests for my implementation which fail when I run them on the commons BinaryHeap. Below is source-code for the JUnit test which fails. The test 'testRandom' is the test that fails. This test creates heaps initialised with 100 randomly generated Integers and proceeds to add and remove random elements from these heaps and then checks the heap order. Some of the elements that are removed may not exist in the heap. Heap order is checked by disassembling the heap using BinaryHeap.pop() and ensuring that subsequent elements are >= earlier elements. The problem appears to be related to the BinaryHeap.remove(Object) method-- if this is commented out the test succeeds. It may be the case that the problem occurs when non-existant elements are removed, but I have not attempted to verify this. --------- BinaryHeapTest.java --------- /* * JASA Java Auction Simulator API * Copyright (C) 2001-2003 Steve Phelps * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License as * published by the Free Software Foundation; either version 2 of * the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * See the GNU General Public License for more details. */ package test.uk.ac.liv.util; import test.uk.ac.liv.PRNGTestSeeds; import junit.framework.*; //import uk.ac.liv.util.*; import org.apache.commons.collections.BinaryHeap; import java.util.Random; import java.util.Iterator; import java.util.LinkedList; public class BinaryHeapTest extends TestCase { BinaryHeap h1; public BinaryHeapTest( String name ) { super(name); } public void setUp() { h1 = new BinaryHeap(); h1.insert(new Integer(1)); h1.insert(new Integer(3)); h1.insert(new Integer(9)); h1.insert(new Integer(3)); h1.insert(new Integer(5)); h1.insert(new Integer(7)); } public void test() { System.out.println("h1 = " + h1); assertTrue( h1.contains(new Integer(3)) ); assertTrue( h1.contains(new Integer(9)) ); assertTrue( h1.contains(new Integer(1)) ); assertTrue( h1.contains(new Integer(5)) ); assertTrue( !h1.contains(new Integer(10)) ); assertTrue( !h1.contains(new Integer(-1)) ); Object x = h1.pop(); System.out.println("h1 after removing first = " + h1); checkOrder(h1); assertTrue( ((Integer) x).equals(new Integer(1))); assertTrue( !h1.contains(new Integer(1)) ); assertTrue( h1.contains(new Integer(3)) ); assertTrue( h1.contains(new Integer(9)) ); assertTrue( h1.contains(new Integer(5)) ); h1.remove(new Integer(9)); System.out.println("h1 after removing 9 = " + h1); assertTrue( h1.contains(new Integer(3)) ); assertTrue( !h1.contains(new Integer(9)) ); assertTrue( h1.remove( new Integer(3) ) ); System.out.println("h1 after removing 3 = " + h1); // assertTrue( ! h1.contains(new Integer(3)) ); x = h1.pop(); System.out.println("h1 after removing first = " + h1); h1.pop(); System.out.println("h1 after removing first = " + h1); assertTrue( h1.remove( new Integer(7) ) ); System.out.println("h1 after removing 7 = " + h1); assertTrue( h1.isEmpty() ); assertTrue( ! h1.remove( new Integer(7) ) ); h1.add( new Integer(666) ); h1.add( new Integer(667) ); assertTrue( h1.remove(new Integer(667)) ); assertTrue( h1.size() == 1 ); assertTrue( ! h1.contains(new Integer(667)) ); assertTrue( h1.remove(new Integer(666)) ); } public void checkOrder( BinaryHeap h ) { System.out.println("Checking order of " + h); Integer lastNum = null; LinkedList l = new LinkedList(); while ( !h.isEmpty() ) { Integer num = (Integer) h.pop(); System.out.println(num); if ( lastNum != null && num.intValue() < lastNum.intValue() ) { System.out.println("!!??*** " + num + " smaller than " + lastNum); } assertTrue( lastNum == null || num.intValue() >= lastNum.intValue() ); lastNum = num; l.add(num); } Iterator it = l.iterator(); while ( it.hasNext() ) { h.add( it.next() ); } } public void testRandom() { Random randGenerator = new Random(PRNGTestSeeds.UNIT_TEST_SEED); for( int i=0; i<1000; i++ ) { BinaryHeap h = new BinaryHeap(); for( int r=0; r<100; r++ ) { h.add( new Integer( randGenerator.nextInt(100)) ); } System.out.println("Starting with heap " + h); for( int r=0; r<20; r++ ) { System.out.println("Attempting to remove " + r); System.out.println("result = " + h.remove( new Integer(r) ) ); Integer n = new Integer( randGenerator.nextInt(100) ); System.out.println("Adding " + n); h.add(n); } checkOrder(h); } } public static void main( String[] args ) { junit.textui.TestRunner.run (suite()); } public static Test suite() { return new TestSuite(BinaryHeapTest.class); } } /* * JASA Java Auction Simulator API * Copyright (C) 2001-2003 Steve Phelps * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License as * published by the Free Software Foundation; either version 2 of * the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * See the GNU General Public License for more details. */ ------- PRNGTestSeeds.java ------- package test.uk.ac.liv; /** * The PRNG seed to use for deterministing unit-testing of seedable classes. * This was introduced for ecj10, which uses a seed based on the * current system time when using the null argument constructor. * * @author Steve Phelps * @version $Revision: 1.2 $ */ public class PRNGTestSeeds { /** * The seed to use for all unit tests. */ public static final long UNIT_TEST_SEED = 1465187; } |
16 years, 13 weeks, 4 days ago | 18920 | No Perforce job exists for this issue. | 0 | 25818 | 164630 | 0|i0sjgn: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-60 | Minor problems in SequencedHashMap and LRUMap |
Bug | Closed | Major | Fixed | Unassigned | Paul Jack | Paul Jack | 09/Jun/02 04:42 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
1. The remove(Object) methods in the keySet and entrySet correctly remove null keys, but incorrectly return false after they do so. 2. The retainAll(Collection) and removeAll(Collection) methods in the collection views do not properly modify the map's modCount, and thus will never cause a ConcurrentModificationException. |
17 years, 43 weeks, 2 days ago | 18938 | No Perforce job exists for this issue. | 0 | 9719 | 164648 | 0|i0sjkn: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-99 | [PATCH] Apidoc fix for MapUtils.java |
Bug | Closed | Minor | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 20/Jun/03 07:36 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | Nightly Builds | 0 | 0 | Operating System: All Platform: All |
This patch fixes two {@link} tags. | 16 years, 41 weeks, 4 days ago | 18899 | No Perforce job exists for this issue. | 1 | 20933 | 164609 | 0|i0sjbz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-57 | Addition of static class modifer to inner classes |
Bug | Closed | Minor | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 20/Jun/03 06:56 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | Nightly Builds | 0 | 0 | Operating System: All Platform: All |
findbugs 0.6.0 suggested that these classes had inner classes which could be made static CursorableLinkedList.java DefaultMapBag.java ExtendedProperties.java StaticBucketMap.java The attached patch file patches these classes in that way. After patching the unit test passed okay. I'm assuming the unit tests passing is proof enough that these changes are okay. |
16 years, 41 weeks, 4 days ago | 18941 | No Perforce job exists for this issue. | 1 | 20931 | 164651 | 0|i0sjlb: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-4 | Calling CollectionUtils.cardinality with null obj argument leads to NPE |
Bug | Closed | Major | Fixed | Unassigned | Serhiy Yevtushenko | Serhiy Yevtushenko | 20/Oct/02 03:27 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
There is a bug in cardinality method, which shows, when obj parameter is null; It leads to NullPointerException. In order to reveal it, add line assertEquals(0, CollectionUtils.cardinality(null, _b)); to testCardinality in TestCollectionUtils. One variant of correct implementation is following: public static int cardinality(Object obj, final Collection col) { int count = 0; Iterator it = col.iterator(); if(null==obj){ while(it.hasNext()){ Object elt = it.next(); if(null==elt){ count++; } } }else{ while(it.hasNext()) { Object elt = it.next(); if(obj.equals(elt)) { count++; } } } return count; } |
17 years, 22 weeks, 3 days ago | 18994 | No Perforce job exists for this issue. | 0 | 13785 | 164704 | 0|i0sjx3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-34 | Collections doesn't build with jdk1.2 javac |
Bug | Closed | Major | Fixed | Unassigned | Jeff Turner | Jeff Turner | 12/May/01 05:46 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | Nightly Builds | 0 | 0 | Operating System: Linux Platform: PC |
Hi, Just tried building jakarta-commons/collections from CVS (12/5), and it doesn't compile with Sun's 'javac' for linux: $ java -version java version "1.2.2" Classic VM (build JDK-1.2.2_007, green threads, nojit) $ ant clean ; ant .... build-java: [mkdir] Created dir: /home/jeff/apache/jakarta/jakarta-commons/collections/dist/classes [javac] Compiling 26 source files to /home/jeff/apache/jakarta/jakarta-commons/collections/dist/classes [javac] /home/jeff/apache/jakarta/jakarta-commons/collections/src/java/org/apache/commons/collections/FastTreeMap.java:325: Inner type Entry in class java.util.TreeMap not accessible from class org.apache.commons.collections.FastTreeMap. [javac] Entry e = (Entry) i.next(); [javac] ^ [javac] .... BUILD FAILED However, it *does* work if I set build.compiler=jikes. It also works if I use jdk1.3 'javac'. Possibly a bug in javac? Anyway, just thought I'd bring this to people's attention, as the STATUS.html file states it needs "JDK1.2 or later". thanks, --Jeff |
18 years, 46 weeks, 5 days ago | 18964 | No Perforce job exists for this issue. | 0 | 1729 | 164674 | 0|i0sjqf: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-31 | [collections][PATCH] BlockingBuffer JavaDoc improvement |
Bug | Closed | Major | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 18/Sep/03 07:13 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
The attached patch improvements the JavaDoc for o.a.c.c.decorators.BlockingBuffer by describing the behaviour of get() and remove() in a multithreaded environment. |
16 years, 28 weeks, 5 days ago | 18967 | No Perforce job exists for this issue. | 1 | 23234 | 164677 | 0|i0sjr3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-89 | [collections][PATCH] TestBlockingBuffer extensions and BlockingBuffer fix |
Bug | Closed | Major | Fixed | Unassigned | Janek Bogucki | Janek Bogucki | 18/Sep/03 06:31 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
The attached patch adds some tests to assert the behaviour of BlockingBuffer.get()/remove()/add()/addAll in various combinations. The discussion that led to this patch can be found at COM-816. Also attached is a patch to change notify() to notifyAll() in BlockingBuffer which allows the tests in TestBlockingBuffer to pass. |
16 years, 28 weeks, 5 days ago | 18909 | No Perforce job exists for this issue. | 2 | 23232 | 164619 | 0|i0sje7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-44 | Upgrade your version number |
Bug | Closed | Minor | Fixed | Unassigned | Arnaud HERITIER | Arnaud HERITIER | 11/Jul/02 21:05 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | Nightly Builds | 0 | 0 | Operating System: other Platform: Other |
Can you update your build xml to modify the component.version property. It is actually setted to 2.0 and should be to 3.0 dev or 2.1 dev ?? Futhermore, the Manifest file is not automatically generated from build.xml properties. I attach a copy of the build.xml and the Manifest files that I modified to automatically update the release number. I let you to choose which number to use in the build.xml. Here are diffs that I done from Cygwin because I can't access to the CVS Repository from my office :-( diff MANIFEST.MF : 5c5 < Implementation-Version: @version@ --- > Implementation-Version: 2.0 diff build.xml : 97,99d96 < <echo message="-------- ${Name-Long} ${component.version} --------"/> < <filter token="version" value="${component.version}"/> < 254,256c251 < <mkdir dir="${workdir}/classes"/> < <mkdir dir="${workdir}/conf"/> < <copy todir="${workdir}/classes"> --- > <copy todir="${workdir}"> 261,263d255 < <copy todir="${workdir}/conf" filtering="on"> < <fileset dir="${source.src}/conf" includes="*.MF"/> < </copy> 268c260 < <jar jarfile="${dest.jardir.jar}" manifest="${workdir}/conf/MANIFEST.MF"> --- > <jar jarfile="${dest.jardir.jar}" manifest="${source.src}/conf/MANIFEST.MF"> |
17 years, 19 weeks, 1 day ago | 18954 | No Perforce job exists for this issue. | 0 | 10686 | 164664 | 0|i0sjo7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-35 | [collections] IteratorChain.hasNext() throws when chain is empty |
Bug | Closed | Major | Fixed | Unassigned | Phil Steitz | Phil Steitz | 08/Nov/03 12:22 | 15/Mar/08 21:35 | 14/Jul/06 12:05 | Nightly Builds | 1 | 0 | Operating System: other Platform: Other |
If added to TestIteratorChain, the following test case fails with the stack trace that follows. The exception is documented in the javadoc for IteratorChain.hasNext(), but the behavior may be inconsistent with the Iterator interface spec. Test case: public void testEmptyChainHasNext() { IteratorChain chain = new IteratorChain(); assertTrue(!chain.hasNext()); } Stack trace: [java] Time: 20.733 [java] There was 1 error: [java] 1) testEmptyChainHasNext(org.apache.commons.collections.iterators.TestIteratorChain) java.lang.UnsupportedOperationException: IteratorChains must contain at least one Iterator [java] at org.apache.commons.collections.iterators.IteratorChain.checkChainIntegrity(IteratorChain.java:248) [java] at org.apache.commons.collections.iterators.IteratorChain.lockChain(IteratorChain.java:256) [java] at org.apache.commons.collections.iterators.IteratorChain.hasNext(IteratorChain.java:295) [java] at org.apache.commons.collections.iterators.TestIteratorChain.testEmptyChainHasNext(TestIteratorChain.java:186) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) |
13 years, 37 weeks, 4 days ago | 18963 | No Perforce job exists for this issue. | 0 | 24520 | 164673 | 0|i0sjq7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-714 | PatriciaTrie ignores trailing null characters in keys |
Bug | Open | Critical | Unresolved | Unassigned | Rohan Padhye | Rohan Padhye | 30/Apr/19 23:11 | 18/Mar/20 02:34 | 04/Nov/19 06:38 | 4.3 | Collection, Map | 0 | 4 | 0 | 1800 | In Java, strings are not null terminated. The string "x" (of length = 1 char) is different from the string "x\u0000" (of length = 2 chars). However, PatriciaTrie does not seem to distinguish between these strings.
To reproduce: {code:java} public void testNullTerminatedKey1() { Map<String, Integer> map = new HashMap<>(); map.put("x", 0); // key of length 1 map.put("x\u0000", 1); // key of length 2 map.put("x\u0000y", 2); // key of length 3 Assert.assertEquals(3, map.size()); // ok, 3 distinct keys PatriciaTrie<Integer> trie = new PatriciaTrie<>(map); Assert.assertEquals(3, trie.size()); // fail; actual=2 }{code} In the above example, the resulting trie has only two keys: "x\u0000" and "x\u0000y". The key "x" gets overwritten. Here is another way to repro the bug: {code:java} public void testNullTerminatedKey2() { PatriciaTrie<Integer> trie = new PatriciaTrie<>(); trie.put("x", 0); Assert.assertTrue(trie.containsKey("x")); // ok trie.put("x\u0000", 1); Assert.assertTrue(trie.containsKey("x")); // fail } {code} In the above example, the key "x" suddenly disappears when an entry with key "x\u0000" is inserted. The PatriciaTrie docs do not mention anything about null-terminated strings. In general, I believe this also breaks the JDK Map contract since the keys "x".equals("x\u0000") is false. This bug was found automatically using JQF: [https://github.com/rohanpadhye/jqf]. |
100% | 100% | 1800 | 0 | 20 weeks, 1 day ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | https://github.com/apache/commons-collections/pull/78 | 0|z02alk: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-697 | JavaDoc for FixedSizeList should warn that modifying underlying list is still allowed and is not prevented |
Bug | Resolved | Major | Fixed | Unassigned | Ranjan George | Ranjan George | 02/Oct/18 17:33 | 18/Mar/20 02:59 | 11/Jan/20 23:54 | 11/Jan/20 23:42 | 4.4 | 4.5 | 0 | 2 | I just noticed that it is not explicitly mentioned in the JavaDoc that modifying the underlying list of a FixedSizeList would actually land up modifying the list of the constructed FixedSizeList. Not sure if this was by design, but at the very list I think the JavaDoc should caution against this.
Following is a test case that written that you could use to check this. {code:java} public void testAllowsMutationOfUnderlyingCollection() { List<String> decoratedList = new ArrayList<>(); decoratedList.add("item 1"); decoratedList.add("item 2"); // FixedSizeList<String> fixedSizeList = FixedSizeList.fixedSizeList(decoratedList); int sizeBefore = fixedSizeList.size(); // boolean changed = decoratedList.add("New Value"); Assert.assertTrue(changed); // Assert.assertEquals("Modifying an the underlying list is allowed", sizeBefore + 1, fixedSizeList.size()); } {code} |
9 weeks, 3 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i3yqvb: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-747 | MultiKey.getKeys class cast exception |
Bug | Resolved | Major | Fixed | Gary D. Gregory | Walter Laan | Walter Laan | 10/Feb/20 14:49 | 17/Feb/20 09:00 | 16/Feb/20 21:28 | 4.4 | 4.5 | KeyValue | 0 | 2 | When using an non-array constructor of MultiKey, an Object[] is created, which cannot be cast to a K[]
{code} import org.apache.commons.collections4.keyvalue.MultiKey; public class MultiKeyClassCastException { public static void main(String[] args) { MultiKeyClassCastException key1 = new MultiKeyClassCastException(); MultiKeyClassCastException key2 = new MultiKeyClassCastException(); MultiKeyClassCastException[] keys = new MultiKey<>(key1, key2).getKeys(); } } // running gives (same error if in module): Exception in thread "main" java.lang.ClassCastException: class [Ljava.lang.Object; cannot be cast to class [LMultiKeyClassCastException; ([Ljava.lang.Object; is in module java.base of loader 'bootstrap'; [LMultiKeyClassCastException; is in unnamed module of loader 'app') at MultiKeyClassCastException.main(MultiKeyClassCastException.java:8) {code} AFAIK, the only way to fix this (with source compatibility), is to only have a varargs constructors. but I think this breaks binary compatibility though and cannot be used with the existing constructors. {code} @SafeVarargs public MultiKey(K... keys) { this.keys = keys; } {code} Workaround is to use array constructor with correct typed array or {code}Object[] keys = multiKey.getKeys();{code} explicitly. |
4 weeks, 1 day ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|z0bbwg: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-741 | Signature of IteratorUtils.objectGraphIterator is wrong |
Bug | Open | Minor | Unresolved | Unassigned | Hans-Peter Stoerr | Hans-Peter Stoerr | 10/Dec/19 19:30 | 10/Dec/19 20:12 | 4.4 | 0 | 1 | With the current signature
Iterator<E> objectGraphIterator(E root, Transformer<? super E,? extends E> transformer) it is impossible to create any other iterator than an Iterator<Object> since the signature for the transformer just doesn't fit. (This problem extends to the underlying [ObjectGraphIterator|https://commons.apache.org/proper/commons-collections/javadocs/api-4.4/org/apache/commons/collections4/iterators/ObjectGraphIterator.html], too.) In the [example from the javadoc|https://commons.apache.org/proper/commons-collections/javadocs/api-4.4/org/apache/commons/collections4/IteratorUtils.html#objectGraphIterator-E-org.apache.commons.collections4.Transformer-], you would want to return an Iterator<Leaf>, but the root is of type Forest (compare the full source in the [ObjectGraphIteratorTest|https://git-wip-us.apache.org/repos/asf?p=commons-collections.git;a=blob;f=src/test/java/org/apache/commons/collections4/iterators/ObjectGraphIteratorTest.java;h=caff4ed312400c2a9e397c55edff2a5839981a68;hb=HEAD] ), the transformer takes either Forest, Tree, Branch or Leaf as argument and returns Leaf or Iterators of Tree, Branch or Leaf. There just is no common bound for these types except Object. I'm afraid there is no way to get some type safety into this signature. So I suggest to just relax it to public static <E> Iterator<E> objectGraphIterator(final Object root, final Transformer<Object, Object> transformer) since Object is the bound for all those arguments, anyway. (In many cases you would have the root and the first type variable the same type E, but the second type variable of the transformer would have to allow for both E and Iterator<E>, and thus be Object. So I'm not sure whether it makes any sense to make any restriction here.) BTW: While that function has been useful for me, I'm a bit unhappy with it, anyway, since I see no acceptable way to use it to return all nodes of a tree, including the inner nodes, with it. At least not without serious hacks like wrapping the returned nodes in an Object[1] array and chain that to the children iterator. |
14 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|z09j88: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-727 | A potential misleading comment |
Bug | Closed | Major | Fixed | Unassigned | XiangzheXu | XiangzheXu | 20/Aug/19 15:20 | 23/Aug/19 20:17 | 23/Aug/19 20:15 | 4.4 | 4.5 | Iterator | 0 | 2 | 300 | 300 | 0% | I was wondering whether there's something wrong in the @throws IndexOutOfBoundsException condition for the `setIterator(final int index, final Iterator<? extends E> iterator)` method in the class `org.apache.commons.collections4.iterators.CollatingIterator<E>`.
The method and its Javadoc comment are shown as follows. /** * Sets the iterator at the given index. * * @param index index of the Iterator to replace * @param iterator Iterator to place at the given index * @throws IndexOutOfBoundsException if index < 0 or index > size() * @throws IllegalStateException if iteration has started * @throws NullPointerException if the iterator is null */ public void setIterator(final int index, final Iterator<? extends E> iterator) { checkNotStarted(); if (iterator == null) { throw new NullPointerException("Iterator must not be null"); } iterators.set(index, iterator); } The boundary of the parameter index is marked as `index < 0 or index > size()` in the comment. Nevertheless, the `set(index, iterator)` method would throw an IndexOutOfBoundsException when the index is equal to `size()`. So it would be better if we could change the boundary in the comment to `index < 0 or index >= size()`. |
0% | 0% | 300 | 300 | JavaDoc | 29 weeks, 4 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|z05ubs: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-756 | CollectionUtils.filter(..) broken with blank Collections.singleton |
Bug | Closed | Major | Not A Problem | Unassigned | noname713705 | noname713705 | 08/Mar/20 22:20 | 18/Mar/20 02:47 | 08/Mar/20 23:29 | 08/Mar/20 23:29 | 4.4 | Collection | 0 | 1 | When using {{CollectionUtils.filter(..)}}, if the passed collection is initialized with jdk {{Collections.singleton(..)}} and only contains an {{isBlank(..)}} string, the method will throw an exception instead of removing blank item as expected. Tested with commons-collections:4.4 and java8.
All can be resumed with {code:java} CollectionUtils.filter(Collections.singleton(" "), StringUtils::isNotBlank); {code} |
1 week, 2 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|z0cb60: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-603 | Small improvements for generics, conditional statements, and warnings suppressions |
Bug | Resolved | Minor | Fixed | Bruno P. Kinoshita | Bruno P. Kinoshita | Bruno P. Kinoshita | 24/May/17 08:02 | 24/May/17 08:21 | 24/May/17 08:21 | 4.2 | Collection | 0 | 1 | Place holder for pull request #17 | 2 years, 42 weeks, 6 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 |
Patch
|
0|i3fe67: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-602 | Improve efficiency of DefaultedMap.get |
Bug | Resolved | Major | Fixed | Bruno P. Kinoshita | John Mark | John Mark | 19/May/17 14:23 | 24/May/17 09:35 | 24/May/17 09:35 | 4.2 | 0 | 2 | The current implementation of {{org.apache.commons.collections4.map.DefaultedMap.get()}} is inefficient since it always require two map lookups. There is no need to check map.containsKey() every time. I would suggest implementing this method similar to the way that Java 8 does with {{Map.getOrDefault()}}. My proposed implementation would be something like this: {code} public V get(final Object key) { V v; return ((v = map.get(key) != null) || map.containsKey(key)) ? v : value.transform((K) key); } {code} It can be further optimized to not even call map.containsKey() if map is known to not contain null values. |
help-wanted | 2 years, 42 weeks, 6 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 1 | 9223372036854775807 | 0|i3f84f: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-679 | MultiValuedMap JavaDoc Typo |
Bug | Resolved | Trivial | Fixed | Unassigned | David Mollitor | David Mollitor | 16/Mar/18 19:02 | 25/Sep/19 14:47 | 25/Sep/19 14:47 | 4.5 | 0 | 2 | 0 | 1200 | https://github.com/apache/commons-collections/blob/36d33722c37417b2fba57106fee185a5e422ee47/src/main/java/org/apache/commons/collections4/MultiValuedMap.java#L35
The example code provided refers to a class called _MultiValuedHashMap_. There is no such class in Commons Collection4. Perhaps _ArrayListValuedHashMap_ is a better example. |
100% | 100% | 1200 | 0 | 24 weeks, 6 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i3rf87: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-662 | Build failures when building with Java 9 |
Bug | Resolved | Major | Fixed | Pascal Schumacher | Vamsi | Vamsi | 12/Oct/17 04:12 | 20/Oct/17 16:33 | 20/Oct/17 14:09 | 0 | 4 | *mvn clean test* fails with following errors when using with java-9
{code:java} Tests in error: MapUtilsTest.testgetByteValue:1051 » ServiceConfiguration sun.util.locale.prov... MapUtilsTest.testgetDoubleValue:956 » ServiceConfiguration sun.util.locale.pro... MapUtilsTest.testgetFloatValue:974 » ServiceConfiguration sun.util.locale.prov... MapUtilsTest.testgetIntValue:1012 » ServiceConfiguration sun.util.locale.provi... MapUtilsTest.testgetLongValue:992 » ServiceConfiguration sun.util.locale.provi... MapUtilsTest.testgetShortValue:1031 » ServiceConfiguration sun.util.locale.pro... ListIteratorWrapperTest.testRemove:116 » ServiceConfiguration sun.util.locale.... Tests run: 16088, Failures: 0, Errors: 7, Skipped: 0 {code} |
2 years, 21 weeks, 4 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i3l60v: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-685 | IterableUtils has public constructor |
Bug | Open | Trivial | Unresolved | Unassigned | Stephan Fuhrmann | Stephan Fuhrmann | 12/Jun/18 06:04 | 12/Jun/18 21:48 | 5.0 | Collection | 0 | 4 | IterableUtils has public constructor. All other Utils classes have their constructor made private to prohibit instantiation. | 1 year, 40 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i3urb3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-716 | Don't include email address in Exception messages |
Bug | Closed | Major | Fixed | Unassigned | Sebb | Sebb | 12/May/19 12:42 | 05/Jul/19 15:26 | 05/Jul/19 15:26 | 4.4 | 0 | 0 | There are several messages in LRUMap which reference dev@commons.
These need to be replaced, see: https://lists.apache.org/thread.html/5c3805daf30768034ae18576b7275b0535b4e5aec839cd13de2103c1@%3Cdev.commons.apache.org%3E |
36 weeks, 4 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|z02lz4: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-683 | README.md contains pointer to non-existing Maven artifact/javadoc |
Bug | Open | Minor | Unresolved | Unassigned | Stephan Fuhrmann | Stephan Fuhrmann | 11/Jun/18 16:47 | 13/Jun/18 08:12 | 0 | 2 | COLLECTIONS-682 | The README.md file contains references to the
* 4.2 maven artefact on maven central (see XML snippet) * 4.2 Javadoc on javadoc.io (see badge) These pointers do not exist and confuse the developers. The current version in fact is 4.1. |
1 year, 40 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i3uqj3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-682 | README.md contains unresolved template references |
Bug | Closed | Trivial | Fixed | Unassigned | Stephan Fuhrmann | Stephan Fuhrmann | 11/Jun/18 16:43 | 12/Jun/18 21:40 | 11/Jun/18 22:51 | 4.2 | 0 | 1 | COLLECTIONS-683 | https://github.com/apache/commons-collections/blob/master/README.md | The README.md file contains an unresolved reference to
{{${project.description}}} |
1 year, 40 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 1 | 9223372036854775807 | 0|i3uqi7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-680 | CollectionUtilsTest test for collect is broken |
Bug | Resolved | Major | Fixed | Unassigned | Konstantinos Angelopoulos | Konstantinos Angelopoulos | 24/Apr/18 15:08 | 12/Jun/18 21:50 | 12/Jun/18 21:50 | Collection | 0 | 2 | Cannot resolve method ConnectionUtils.collect in line 1289. | 1 year, 40 weeks ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i3syjb: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-686 | Coveralls.io set to wrong branch? |
Bug | Open | Trivial | Unresolved | Unassigned | Stephan Fuhrmann | Stephan Fuhrmann | 13/Jun/18 17:40 | 13/Jun/18 17:40 | 0 | 1 | [https://coveralls.io/github/apache/commons-collections?branch=master]
[https://coveralls.io/github/apache/commons-collections] |
According to
[https://coveralls.io/github/apache/commons-collections] the default branch is *trunk* and has 85% coverage (last commit June 2017). But the real working github branch is *master* and has 87% coverage. This is why the coveralls badge on Github shows 85% I guess. I suggest switching the default branch on coveralls from trunk to master. |
1 year, 39 weeks, 6 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i3utqn: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-663 | Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap |
Bug | Open | Trivial | Unresolved | Bruno P. Kinoshita | Christophe Schmaltz | Christophe Schmaltz | 04/Nov/17 17:38 | 06/Nov/19 07:23 | 0 | 4 | 0 | 600 | Testcase:
{code} @Test public void test() { MultiValuedMap<Integer, Integer> multiMap = new HashSetValuedHashMap<>(); multiMap.put(1, 10); multiMap.put(2, 20); for (Collection<Integer> innerCollection : multiMap.asMap().values()) { for (Iterator<Integer> iterator = innerCollection.iterator(); iterator.hasNext();) { Integer i = iterator.next(); iterator.remove(); // only the innerCollection is altered } // innerCollection.add(6); // adding stuff back should also work... } }{code} This test unexpectedly throws a ConcurrentModificationException. The issue is that when calling {{iterator.remove()}} the {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is empty and calls {{AbstractMultiValuedMap.this.remove(key);}}. It may be better if the iterator of the inner collection had a reference on the iterator if the outer map and called {{containerIterator.remove()}} instead. *Note:* this solution would again present issues if the user tries to add new elements in this now empty collection (which was removed from the parent). In the current state, it is quite unclear why an exception is thrown, without debugging the code. |
100% | 100% | 600 | 0 | 18 weeks, 6 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i3meo7: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-732 | Got an UnsupportedOperationException when using MultiValuedMap.MapIterator().setValue() |
Bug | Open | Major | Unresolved | Unassigned | Chen | Chen | 05/Nov/19 12:36 | 18/Mar/20 02:46 | 18/Jan/20 08:47 | Map | 0 | 2 | copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
{code:java} public void testSetValueMapIterator(){ final ListValuedMap<String, String> listMap = new ArrayListValuedHashMap<>(); List<String> listA = listMap.get("A"); listA.addAll(0, Arrays.asList("W", "X", "F")); List<String> listB = listMap.get("B"); listB.addAll(0, Arrays.asList("Q", "Q", "L")); assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString()); for(MapIterator<String, String> iterator = listMap.mapIterator(); iterator.hasNext(); ){ iterator.next(); String value = iterator.getValue(); if(value == "F"){ iterator.setValue("B"); } } assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString()); } {code} It throws an UnsupportedOperationException when altering mapIterator().setValue()。 I found UnsupportedOperationException is thrown in the code of setValue。So,if setValue method is not supported,the Javadoc should comment it。 |
8 weeks, 3 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|z089tk: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-445 | Several unit test failures with IBM JDK 6 |
Bug | Closed | Blocker | Fixed | Unassigned | Thomas Neidhart | Thomas Neidhart | 26/Feb/13 21:21 | 09/Nov/14 14:31 | 21/Apr/13 17:48 | 4.0-alpha1, 4.0 | 0 | 0 | Failed tests: AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's Test: [] Real: [value] expected:<1> but was:<0> AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's Test: [] Real: [value, value, seev, tmpv, we'llv, youv] expected:<6> but was:<0> AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionClear:638->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv Test: [] Real: [] AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRemoveAll:930->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv Test: [] Real: [] AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRetainAll:973->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv Test: [] Real: [] AbstractMapTest$TestMapEntrySet>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0> AbstractMapTest$TestMapKeySet>AbstractCollectionTest.testCollectionRemove:881 Collection should remove extant element: key AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0> AbstractIterableMapTest$InnerTestMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<againv> AbstractIterableMapTest$InnerTestMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<again> AbstractBidiMapTest$TestBidiMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<again> AbstractBidiMapTest$TestInverseBidiMap>AbstractBidiMapTest.testBidiMapIteratorSet:560 expected same:<For> was not:<again> AbstractBidiMapTest$TestBidiMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<againv> DualTreeBidiMapTest>AbstractBidiMapTest.testBidiMapIteratorSet:560 expected same:<For> was not:<againv> AbstractOrderedBidiMapTest$TestBidiOrderedMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<againv> AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's Test: [] Real: [value] expected:<1> but was:<0> AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's Test: [] Real: [value, value2, seev, tmpv, we'llv, youv] expected:<6> but was:<0> AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionClear:638->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv Test: [] Real: [] AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRemoveAll:930->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv Test: [] Real: [] AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRetainAll:973->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv Test: [] Real: [] AbstractMapTest$TestMapEntrySet>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0> AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0> AbstractIterableMapTest$InnerTestMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<youv> AbstractIterableMapTest$InnerTestMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<you> AbstractBidiMapTest$TestBidiMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<you> AbstractBidiMapTest$TestInverseBidiMap>AbstractBidiMapTest.testBidiMapIteratorSet:560 expected same:<For> was not:<you> AbstractBidiMapTest$TestBidiMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<youv> DualTreeBidiMap2Test>AbstractBidiMapTest.testBidiMapIteratorSet:560 expected same:<For> was not:<youv> AbstractOrderedBidiMapTest$TestBidiOrderedMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<youv> AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's Test: [] Real: [foov] expected:<1> but was:<0> AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's Test: [] Real: [againv, allv, barv, bazv, blahv, foov] expected:<6> but was:<0> AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionClear:638->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: youv Test: [] Real: [] AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRemoveAll:930->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: youv Test: [] Real: [] AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRetainAll:973->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: youv Test: [] Real: [] AbstractMapTest$TestMapEntrySet>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0> AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0> Tests in error: AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer |
6 years, 48 weeks, 2 days ago | 314784 | No Perforce job exists for this issue. | 1 | 315128 | 0|i1ibjb: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-408 | performance problem in SetUniqueList.removeAll() |
Bug | Closed | Major | Fixed | Unassigned | Adrian Nistor | Adrian Nistor | 02/Jun/12 06:56 | 09/Nov/14 14:31 | 19/Jun/12 19:22 | 4.0-alpha1, 4.0 | 0 | 2 | COLLECTIONS-407 | java 1.6.0_24 Ubuntu 11.10 |
Hi, I am encountering a performance problem in SetUniqueList.removeAll(). It appears in version 3.2.1 and also in revision 1344775 (31 May 2012). I have attached a test that exposes this problem and a one-line patch that fixes it. The patch makes the code two times faster for this test. To run the test, just do: $ java Test The output for the un-patched version is: Time is: 5027 The output for the patched version is: Time is: 2554 The one-line patch I attached changes the SetUniqueList.removeAll(Collection<?> coll) code from: boolean result = super.removeAll(coll); set.removeAll(coll); return result; to: boolean result = super.removeAll(coll); if (result) set.removeAll(coll); return result; If "super.removeAll(coll)" did not change the collection, there is no need to call "set.removeAll(coll)", because we already know there is nothing to remove. As one may expect "set.removeAll(coll)" (on a set) to be faster than "super.removeAll(coll)" (on a list), one may have expected the speedup gained by avoiding "set.removeAll(coll)" to be smaller than 2X achieved for the attached test. However, the speedup is 2X because "java.util.HashSet.removeAll(Collection<?> collection)" has quadratic (not linear) complexity if "this.size() <= collection.size()" and the "collection" is a list. Thus, "set.removeAll(coll)" is about as slow as "super.removeAll(coll)" in this case, and not executing "set.removeAll(coll)" reduces the work done by half. The quadratic behavior of "java.util.HashSet.removeAll(Collection<?> collection)" comes from "java.util.AbstractSet.removeAll(Collection<?> c)" and is discussed for example here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007148.html (The link is for OpenJDK, but Oracle JDK has the same problem.) In many other cases "set.removeAll(coll)" is actually faster than "super.removeAll(coll)", so one can get even more speedup by reordering those two checks: boolean result = set.removeAll(coll); if (result) super.removeAll(coll); return result; Is this a bug, or am I misunderstanding the intended behavior? If so, can you please confirm that the patch is correct? Thanks, Adrian |
7 years, 40 weeks ago | 292950 | No Perforce job exists for this issue. | 2 | 164352 | 0|i0shqv: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-473 | AbstractCollectionDecorator.decorated() should not be used internally |
Bug | Closed | Major | Fixed | Unassigned | Sebb | Sebb | 17/Jun/13 22:17 | 09/Nov/14 14:31 | 18/Jun/13 20:29 | 4.0-alpha1, 4.0 | 0 | 0 | AbstractCollectionDecorator.decorated() is used internally to access the collection. However, the method is not final, so subclasses could override it. Yet the field is also exposed (protected). This is inconsistent. Is there any use-case for overriding the collection to use a different one? If so, having direct access as well is likely to cause problems. I think it would be better to use the field directly internally. The class Javadoc says the calls are forwarded to the underlying collection, but that is not strictly true if decorated() is overridden. If it is intended to allow this to be overridden, then the field needs to be protected against arbitrary read/write access. The field should probably be made private with a setter for use by deserialization only. |
6 years, 40 weeks ago | 333609 | No Perforce job exists for this issue. | 0 | 333937 | 0|i1ljsn: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-468 | Change Bag interface and implementations to conform to Collection interface |
Bug | Closed | Major | Fixed | Unassigned | Thomas Neidhart | Thomas Neidhart | 13/May/13 20:57 | 09/Nov/14 14:31 | 17/Jun/13 21:06 | 4.0-alpha1, 4.0 | 0 | 1 | Several methods of the Bag interface do not conform to the Collection interface (e.g. add, remove, containsAll, removeAll, retainAll). This should be fixed for 4.0. |
6 years, 37 weeks, 4 days ago | 327730 | No Perforce job exists for this issue. | 3 | 328074 | 0|i1kjnz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-461 | splitmap.TransformedMap is not really a Map |
Bug | Closed | Major | Fixed | Unassigned | Sebb | Sebb | 06/May/13 10:16 | 09/Nov/14 14:31 | 14/May/13 20:02 | 4.0-alpha1, 4.0 | 0 | 1 | splitmap.TransformedMap is part of the Get/Put hierarchy, but it does not behave like a proper Java Map. In particular, java.util.Map.put(K, V) returns V. However the collections Put interface returns Object. As far as I can tell, this was done in order to be able to include TransformedMap in the hiearchy. But the side effect is to break the generics for all the non-transformer maps in the hierarchy. Maybe there should be a separate PutTransformed interface which has the appropriate generic types, i.e. public T put(K key, V value) |
6 years, 45 weeks ago | 326546 | No Perforce job exists for this issue. | 0 | 326891 | 0|i1kc3b: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-458 | AbstractUntypedCollectionDecorator<E, D> is not used |
Bug | Closed | Major | Fixed | Unassigned | Sebb | Sebb | 29/Apr/13 22:20 | 27/Nov/15 21:11 | 30/Apr/13 12:00 | 0 | 0 | The public ctor for AbstractUntypedCollectionDecorator<E, D> takes no argument and so collection = null; however the protected ctor checks for collection parameter != null. The decorated() method says that all access to collection goes through it, and there is no setter. At present the only way to recover from calling the public ctor is for the sub-class to set collection directly. This is inconsistent. The class is abstract and there appear to be no concrete subclasses. Looks like the class might be superfluous, but if it is required, it should ideally have a private final collection field. |
6 years, 47 weeks ago | 325684 | No Perforce job exists for this issue. | 0 | 326029 | 0|i1k6rz: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-459 | ArrayIterator & ObjectArrayIterator - do they need setters?` |
Bug | Closed | Major | Fixed | Unassigned | Sebb | Sebb | 30/Apr/13 12:15 | 09/Nov/14 14:31 | 18/Jun/13 19:35 | 4.0-alpha1, 4.0 | 0 | 0 | ArrayIterator & ObjectArrayIterator both have methods to set the array separately from the ctor. However the method does not allow the same flexibility as the ctor, as it does not allow the start or end indexes to be set. Is there really a use-case for these setters? If not, all the fields apart from index could be made final, which would make thread safety (and testing) easier. |
6 years, 40 weeks ago | 325781 | No Perforce job exists for this issue. | 0 | 326126 | 0|i1k7dj: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-455 | AbstractDualBidiMap<K, V> has several mutable protected fields |
Bug | Closed | Major | Fixed | Unassigned | Sebb | Sebb | 29/Apr/13 00:05 | 09/Nov/14 14:31 | 18/Jun/13 20:55 | 4.0-alpha1, 4.0 | 0 | 0 | Any non-private mutable fields make it much harder to ensure thread-safety as well as making it very difficult to test thoroughly. The fields should be made private. If protected write access really is needed, setter methods should be used. These methods can take any necessary precautions to ensure thread-safety. |
6 years, 40 weeks ago | 325480 | No Perforce job exists for this issue. | 0 | 325825 | 0|i1k5in: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-588 | Redundant computation in CollectionBag and CollectionSortedBag |
Bug | Open | Major | Unresolved | Unassigned | Monika Dhok | Monika Dhok | 02/May/16 16:18 | 12/Jan/20 00:47 | 0 | 2 | There appears to be redundant computations in "CollectionBag.retainAll" method in the version 4.4.1. I have attached a test and proposed a small patch which ensures that "contains" method is called on hashset of input collection. This patch gives 892X speed up on my machine for the provided test. Similar patches can be applied for, "CollectionSortedBag.retainAll". |
9 weeks, 3 days ago | 9223372036854775807 | No Perforce job exists for this issue. | 2 | 9223372036854775807 |
Patch
|
0|i2x1pz: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-583 | JAVA serialization vulnerability "CVE-2015-4852" in commons-collections*.jar |
Bug | Resolved | Major | Duplicate | Unassigned | Arnoj Saha | Arnoj Saha | 14/Dec/15 07:02 | 14/Dec/15 07:47 | 14/Dec/15 07:47 | 3.2.2, 4.1 | 0 | 2 | COLLECTIONS-580 | The vulnerability we are talking about is known under number CVE-2015-4852. As far as we know this is only related to the file commons-collections*.jar. In this jar file is a class that takes care of the deserialization. Currently we are using commons-collections-3.2.1.jar. Is there a version of this jar that does not have this vulnerability? |
4 years, 14 weeks, 1 day ago | 9223372036854775807 | No Perforce job exists for this issue. | 0 | 9223372036854775807 | 0|i2pucf: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-438 | ExtendedProperties : String only composed of spaces character |
Bug | Closed | Major | Invalid | Unassigned | Guillaume Chauvet | Guillaume Chauvet | 28/Dec/12 09:00 | 27/Nov/15 21:47 | 22/Jan/13 13:56 | Collection | 0 | 1 | We have discovered a bug in ExtendedProperties class used in our internal language manager framework. The cause are strings which contains only spaces character. We provide a patch to complete the JUnit class ExtendedPropertiesTest. | 7 years, 9 weeks, 2 days ago | 301949 | No Perforce job exists for this issue. | 1 | 248577 | 0|i16xlr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-437 | CollectionUtils.removeAll invoke ListUtils.retainAll !!! |
Bug | Closed | Critical | Duplicate | Unassigned | qxo | qxo | 26/Dec/12 07:04 | 09/Nov/14 14:31 | 28/Feb/13 18:38 | 4.0-alpha1, 4.0 | 0 | 2 | COLLECTIONS-219 | public static Collection removeAll(Collection collection, Collection remove) { return ListUtils.retainAll(collection, remove); } |
7 years, 12 weeks, 3 days ago | 301779 | No Perforce job exists for this issue. | 0 | 248392 | 0|i16wgv: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-449 | Latest Version is set to 20040616 |
Bug | Closed | Critical | Won't Fix | Joerg Schaible | Kai Cabuslay | Kai Cabuslay | 14/Mar/13 02:50 | 14/Mar/13 07:28 | 14/Mar/13 07:28 | 0 | 2 | The current maven metadata file for commons-collections shows that the "latest version" is 20040616. This is currently affecting spring-webmvc (3.1.3-RELEASE) - causing it to use the outdated version of the collections package. http://repo1.maven.org/maven2/commons-collections/commons-collections/maven-metadata.xml |
7 years, 1 week, 5 days ago | 317440 | No Perforce job exists for this issue. | 0 | 317781 | 0|i1irwf: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-421 | Update JavaDoc in ListUtils to discribe generified methods |
Bug | Closed | Trivial | Fixed | Unassigned | Benedikt Ritter | Benedikt Ritter | 07/Jul/12 14:47 | 09/Nov/14 14:31 | 14/Jul/12 21:36 | 4.0-alpha1, 4.0 | Collection | 0 | 2 | The JavaDoc of {{ListUtils.lazyList()}} and {{ListUtils.fixedSizeList}} still refer to the old methods prior to generics. This should be updated. | 7 years, 36 weeks, 2 days ago | 292942 | No Perforce job exists for this issue. | 1 | 164344 | 0|i0shp3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-412 | CollectionUtils.subtract() is very slow |
Bug | Closed | Major | Fixed | Unassigned | Adrian Nistor | Adrian Nistor | 20/Jun/12 20:44 | 09/Nov/14 14:31 | 23/Jun/12 11:34 | 4.0-alpha1, 4.0 | 0 | 2 | java 1.6.0_24 Ubuntu 11.10 |
Hi, I am encountering a performance problem in CollectionUtils.subtract(). It appears in version 3.2.1 and also in revision 1352300 (20 June 2012). I attached a test that exposes this problem and a patch that fixes it. On my machine, for this test, the patch provides a 204X speedup. To run the test, just do: $ java Test The output for the un-patched version is: Time is 11036 The output for the patched version is: Time is 54 The root cause of this problem is similar to the root cause of the previously fixed COLLECTIONS-406 in ListUtils.subtract(), i.e., quadratic complexity instead of linear complexity. This problem affects two methods: CollectionUtils.subtract(final Iterable<? extends O> a, final Iterable<? extends O> b) and CollectionUtils.subtract(final Iterable<? extends O> a, final Iterable<? extends O> b, final Predicate<O> p) because the former just calls the latter. Currently, the code for "CollectionUtils.subtract(final Iterable<? extends O> a, final Iterable<? extends O> b, final Predicate<O> p)" is: ArrayList<O> list = new ArrayList<O>(); addAll(list, a); for (O element : b) { if (p.evaluate(element)) { list.remove(element); } } which is quadratic, because "list.remove(element)" has linear complexity for "ArrayList<O> list = new ArrayList<O>()". The attached patch makes the remove() be constant complexity by removing from an org.apache.commons.collections.bag.HashBag. The attached patch is very similar to the patch of COLLECTIONS-406, so I assume the risk of applying this patch is minimal. Just like in the patch for COLLECTIONS-406, this patch uses a HashBag (and not a HashSet) to respect cardinality when there are repeated objects. Can you please confirm if the patch is correct? Thanks, Adrian |
7 years, 39 weeks, 3 days ago | 292946 | No Perforce job exists for this issue. | 2 | 164348 | 0|i0shpz: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-411 | Exception in ListOrderedMap.putAll() |
Bug | Closed | Major | Fixed | Unassigned | Adrian Nistor | Adrian Nistor | 20/Jun/12 15:45 | 09/Nov/14 14:31 | 20/Jun/12 17:54 | 4.0-alpha1, 4.0 | 0 | 2 | java 1.6.0_24 Ubuntu 11.10 |
Hi, I am encountering an IndexOutOfBoundsException in ListOrderedMap.putAll(int index, Map<? extends K, ? extends V> map). It appears in revision 1351903 (20 June 2012). I have attached a test that exposes this problem. To run the test, just do: $ java Test The output is: ...................................................................... Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 5, Size: 4 at java.util.ArrayList.add(ArrayList.java:367) at org.apache.commons.collections.map.ListOrderedMap.put(ListOrderedMap.java:437) at org.apache.commons.collections.map.ListOrderedMap.putAll(ListOrderedMap.java:245) at Test.main(Test.java:19) ...................................................................... The documentation does not specify anything like this. Is this a bug, or should the documentation just be updated? If the former, is there a patch for it? Thanks, Adrian |
7 years, 39 weeks, 6 days ago | 292947 | No Perforce job exists for this issue. | 1 | 164349 | 0|i0shq7: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-410 | SetUniqueList.addAll() is very slow |
Bug | Closed | Major | Fixed | Unassigned | Adrian Nistor | Adrian Nistor | 19/Jun/12 20:37 | 09/Nov/14 14:31 | 20/Jun/12 18:04 | 4.0-alpha1, 4.0 | 0 | 3 | java 1.6.0_24 Ubuntu 11.10 |
Hi, I am encountering a performance problem in SetUniqueList.addAll(). It appears in revision 1351837 (19 June 2012). I attached a test that exposes this problem and a patch that fixes it. On my machine, for this test, the patch provides a 540X speedup. To run the test, just do: $ java Test The output for the un-patched version is: Time is 2706 The output for the patched version is: Time is 5 As the patch shows, the problem is that SetUniqueList.addAll(int index, Collection<? extends E> coll) performs: "add(index, e)" for each element in "coll". This is very expensive, because each "add(index, e)" performs a LinkedList.add(int index, E element), which requires traversing the LinkedList to find the index. The patched version avoids this cost by inserting all the elements at once, thus performing only one insert. Is this a bug? If so, can you please confirm that the patch is correct? Thanks, Adrian |
7 years, 39 weeks, 6 days ago | 292948 | No Perforce job exists for this issue. | 2 | 164350 | 0|i0shqf: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-527 | Please create a version commons-collections 3.x for jdk 8 compatibility |
Bug | Closed | Blocker | Won't Fix | Unassigned | Ignat Alexeyenko | Ignat Alexeyenko | 15/May/14 10:12 | 27/Nov/15 21:47 | 16/May/14 23:00 | 0 | 3 | Could you make a 3.x or 3.2.x release compatible with JDK8 ? {code} org.apache.commons.collections.MultiMap { public Object remove(Object key, Object item); } {code} is not compatible with JDK's 8 Map {code} java.util.Map { boolean remove(Object key, Object value); } {code} This causes bugs in projects, who run jdk8 and even compilation failures - for these, who implement common's MultiMap. *Compilation Error* If anyone implement MultiMap in their code, compilation fails with the error: {code} MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap cannot implement remove(Object,Object) in Map [ERROR] return type Object is not compatible with boolean {code} *Reasoning* JDK 8 is here and being adopted. collection-commons are not yet compatible with Java 8. For many big project switch to commons-collections 4.x is not an option - some transitional release version needs to be required. Alternative would be for companies to fork commons-collections and create their internal artifact. Why do it if the official compatibility version can be created? Thanks! |
java8, jdk8 | 5 years, 44 weeks, 4 days ago | 392748 | No Perforce job exists for this issue. | 1 | 392924 | 0|i1vmtr: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-521 | Typo in MultiMapKey's isEqualKey(entry, key1, key2) |
Bug | Closed | Major | Fixed | Unassigned | Maxime Nay | Maxime Nay | 01/May/14 20:51 | 27/Nov/15 21:11 | 06/May/14 21:38 | 4.1 | 0 | 2 | I believe there is a typo line 252 in MultiKeyMap. return multi.size() == 2 && (key1 == multi.getKey(0) || key1 != null && key1.equals(multi.getKey(0))) && (key2 == multi.getKey(1) || key1 != null && key2.equals(multi.getKey(1))); should be: return multi.size() == 2 && (key1 == multi.getKey(0) || key1 != null && key1.equals(multi.getKey(0))) && (key2 == multi.getKey(1) || key2 != null && key2.equals(multi.getKey(1))); |
5 years, 44 weeks, 2 days ago | 390113 | No Perforce job exists for this issue. | 0 | 390350 | 0|i1v71r: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-332 | ListOrderedMap not respecting underlying list |
Bug | Closed | Minor | Fixed | Unassigned | Tom Parker | Tom Parker | 10/Jul/09 02:24 | 09/Nov/14 14:31 | 08/Mar/11 21:34 | 4.0-alpha1, 4.0 | Map | 0 | 1 | When decorating either CaseInsensitiveMap or IdentityMap (and I believe this will impact any java.util.TreeMap built with a non-.equals() Comparator), ListOrderedMap responds inconsistently with the underlying map. The ordering seems to be operating off .equals() rather than the actual contents of the underlying map. |
9 years, 3 weeks ago | 18671 | No Perforce job exists for this issue. | 1 | 164409 | 0|i0si3j: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-330 | ConcurrentModificationException using remove from the keySet the LRUMap |
Bug | Closed | Major | Fixed | Unassigned | Joerg Schaible | Joerg Schaible | 17/Jun/09 09:52 | 09/Nov/14 14:31 | 21/Feb/11 19:17 | 4.0-alpha1, 4.0 | Collection | 0 | 0 | COLLECTIONS-3 | Even if the access to a LRUMap is synced and the remove method of the iterator is used that has been returned from the keySet of the LRUMap, it is possible to get a ConcurrentModificationException. This does not happen for remove of the iterators returned by the entrySet or values of the LRUMap. See currently not executed unit test in TestLRUMap (marked as TODO for COLLECTION-3). | 9 years, 5 weeks, 1 day ago | 18673 | No Perforce job exists for this issue. | 0 | 164411 | 0|i0si3z: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-380 | UnmodifiableBoundedCollection.unmodifiableBoundedCollection is an infinite loop |
Bug | Closed | Minor | Fixed | Unassigned | Dave Brosius | Dave Brosius | 29/Sep/11 18:45 | 09/Nov/14 14:31 | 09/Apr/12 18:41 | 4.0-alpha1, 4.0 | Collection | 0 | 0 | This method, just calls itself. As BoundedCollection extends Collection, it would seem to me that this method should be removed: /** * Factory method to create an unmodifiable bounded collection. * * @param coll the <code>BoundedCollection</code> to decorate, must not be null * @return a new unmodifiable bounded collection * @throws IllegalArgumentException if bag is null */ public static <E> BoundedCollection<E> unmodifiableBoundedCollection(BoundedCollection<E> coll) { return unmodifiableBoundedCollection(coll); } |
7 years, 50 weeks, 1 day ago | 40352 | No Perforce job exists for this issue. | 0 | 164374 | 0|i0shvr: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-364 | DualTreeBidiMap.readObject() uses wrong comparator to create reverseMap |
Bug | Closed | Major | Fixed | Sebb | Sebb | Sebb | 18/Oct/10 18:51 | 27/Nov/15 21:11 | 18/Oct/10 19:17 | BidiMap | 0 | 0 | DualTreeBidiMap.readObject() uses the wrong comparator to create reverseMap. The code reads: bq. reverseMap = new TreeMap(comparator); it should read: bq. reverseMap = new TreeMap(valueComparator); Note: this was found when trying to fix generics warnings. |
9 years, 23 weeks, 1 day ago | 18639 | No Perforce job exists for this issue. | 0 | 164384 | 0|i0shxz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-378 | Incorrect links in JavaDoc |
Bug | Closed | Major | Implemented | Unassigned | Ken Dombeck | Ken Dombeck | 08/Aug/11 16:54 | 09/Nov/14 14:31 | 28/Feb/13 19:17 | 4.0-alpha1, 4.0 | 0 | 0 | COLLECTIONS-251 | The links for several JavaDocs were not updated during the implementation of COLLECTIONS-251. Attached patch file includes the necessary changes. |
7 years, 50 weeks, 1 day ago | 18625 | No Perforce job exists for this issue. | 1 | 164376 | 0|i0shw7: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-340 | NOPClosure has a broken equals method |
Bug | Closed | Minor | Fixed | Unassigned | Goran Hacek | Goran Hacek | 14/Oct/09 11:45 | 09/Nov/14 14:31 | 28/Feb/13 19:55 | 4.0-alpha1, 4.0 | Functor | 0 | 0 | Equals method of NOPClosure class doesn't follow objects equals contract. It isn't symmetric nor transitive and it is just plain wrong. Following code evaluates to true on most (if not all) JVM implementations: {noformat} NOPClosure.INSTANCE.equals(new Integer(System.identityHashCode(NOPClosure.INSTANCE))) {noformat} |
6 years, 48 weeks ago | 18663 | No Perforce job exists for this issue. | 0 | 164402 | 0|i0si1z: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-334 | map.StaticBucketMap.size() needs to synchronize access to lock |
Bug | Closed | Major | Fixed | Jochen Wiedmann | Sebb | Sebb | 11/Sep/09 17:46 | 08/Nov/15 21:07 | 01/Mar/11 22:36 | 3.2.2, 4.0-alpha1, 4.0 | Collection | 0 | 0 | collections_jdk5_branch | The field Lock.size is updated using synchronization, however the StaticBucketMap.size() method reads the values without synch. If the read is done in a different thread from the updates, there is no guarantee that the reading thread will see the most recent value. |
9 years, 4 weeks ago | 18669 | No Perforce job exists for this issue. | 0 | 164408 | 0|i0si3b: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-343 | Functor singleton classes do not implement singleton pattern correctly |
Bug | Closed | Major | Fixed | Unassigned | Goran Hacek | Goran Hacek | 15/Oct/09 12:15 | 09/Nov/14 14:31 | 28/Feb/13 19:37 | 4.0-alpha1, 4.0 | Functor | 0 | 0 | All classes in package "org.apache.commons.collections.functors" that advertise that they have singleton instance actually cannot guarantee that. Because of serialization support multiple instances of those classes can exist at runtime. Following classes are making this false claim: * CloneTransformer * ExceptionClosure * ExceptionFactory * ExceptionPredicate * ExceptionTransformer * FalsePredicate * NOPClosure * NOPTransformer * NotNullPredicate * NullPredicate * StringValueTransformer * TruePredicate |
10 years, 13 weeks ago | 18660 | No Perforce job exists for this issue. | 1 | 164400 | 0|i0si1j: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-335 | bidimap.TreeBidiMap.entrySet is never written |
Bug | Closed | Major | Fixed | Jochen Wiedmann | Sebb | Sebb | 11/Sep/09 22:17 | 07/Nov/15 20:31 | 01/Mar/11 22:28 | 3.2.2, 4.0-alpha1, 4.0 | 0 | 0 | The field bidimap.TreeBidiMap.entrySet is never written. Looks like it was perhaps intended to be used as a cache, but the cache value is not written. |
9 years, 4 weeks ago | 18668 | No Perforce job exists for this issue. | 0 | 164407 | 0|i0si33: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-337 | BasicPredicateTestBase.assertFalse & BasicPredicateTestBase.assertTrue methods have confusing names |
Bug | Closed | Major | Won't Fix | Unassigned | Sebb | Sebb | 15/Sep/09 19:32 | 19/Jun/10 19:43 | 19/Jun/10 19:43 | 0 | 0 | BasicPredicateTestBase.assertFalse & BasicPredicateTestBase.assertTrue methods have confusing names - they are the same as the JUnit names, but don't override them. Of course it's still possible to use the JUnit versions of the methods, but the code is harder to understand. |
9 years, 40 weeks, 3 days ago | 18666 | No Perforce job exists for this issue. | 0 | 164405 | 0|i0si2n: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-299 | ExtendedProperties.convertProperties loses non-String values |
Bug | Closed | Major | Fixed | Unassigned | Simon Kitching | Simon Kitching | 16/Jun/08 11:13 | 27/Nov/15 21:11 | 28/Feb/13 19:37 | Core | 0 | 0 | COLLECTIONS-351 | A Properties object normally has Strings as its values. But it does partially support non-String-typed values via the raw put and get methods inherited from Hashtable. And other Properties methods are aware that the value might not be a String; see documentation for methods propertyNames() and stringPropertyNames() for example. ExtendedProperties.convertProperties does this: {code} for (Enumeration e = props.propertyNames(); e.hasMoreElements();) { String s = (String) e.nextElement(); c.setProperty(s, props.getProperty(s)); } {code} Properties.propertyNames() returns the names of all keys in the set, regardless of the associated value's type. But Properties.getProperty(key) returns null if the value type is not a String. The call to c.setProperty invokes setPropertyInternal, which can pass this null value to Hashtable.put, which then throws a NullPointerException. It's rather puzzling to have a valid (string-key, non-string-value) entry in the Properties object and get a NullPointerException. Perhaps the call props.getProperty(s) can be changed to props.get(s) Alternately, at least documenting that this method does not support non-string values in the input Properties object would be useful. |
6 years, 48 weeks ago | 18702 | No Perforce job exists for this issue. | 0 | 164434 | 0|i0si93: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-321 | ComparableComparator.getInstance() not compilable with jdk-compiler |
Bug | Closed | Major | Fixed | Unassigned | Daniel Golesny | Daniel Golesny | 24/Feb/09 11:10 | 09/Nov/14 14:31 | 28/Feb/13 20:24 | 4.0-alpha1, 4.0 | Comparator | 0 | 1 | Comparator<Integer> c = ComparableComparator.getInstance(); This line is valid with eclipse (3.4) compiler, but the jdk 1.5.0 compiler returns this error: [javac] J:\workspace\ndt\cobolclipse-TRUNK\collections_jdk5_branch\src\java\org\apache\commons\collections\comparators\ComparableComparatorTest.java:23: incompatible types; no instance(s) of type variable(s) E exist so that org.apache.commons.collections.comparators.ComparableComparator<E> conforms to java.util.Comparator<java.lang.Integer> [javac] found : <E>org.apache.commons.collections.comparators.ComparableComparator<E> [javac] required: java.util.Comparator<java.lang.Integer> [javac] Comparator<Integer> c = ComparableComparator.getInstance(); [javac] ^ [javac] 1 error |
10 years, 28 weeks, 4 days ago | 18680 | No Perforce job exists for this issue. | 0 | 164416 | 0|i0si53: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-320 | StaticBucketMap#putall() uses inefficient keySet() iterator when it could use entrySet() iterator |
Bug | Closed | Minor | Fixed | Unassigned | Sebb | Sebb | 16/Feb/09 21:58 | 09/Nov/14 14:31 | 28/Feb/13 19:58 | 4.0-alpha1, 4.0 | Map | 0 | 0 | StaticBucketMap#putall() uses inefficient keySet() iterator when it could use entrySet() iterator. Patch to follow. |
10 years, 48 weeks, 6 days ago | 18681 | No Perforce job exists for this issue. | 1 | 164417 | 0|i0si5b: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-319 | IteratorUtils.getIterator(Object obj) performs redundant null check |
Bug | Closed | Minor | Fixed | Unassigned | Sebb | Sebb | 16/Feb/09 19:35 | 09/Nov/14 14:31 | 28/Feb/13 20:24 | 4.0-alpha1, 4.0 | Collection | 0 | 0 | IteratorUtils.getIterator(Object obj) performs redundant null check: {code} if (obj == null) { return emptyIterator(); ... } else if (obj != null && obj.getClass().isArray()) { return new ArrayIterator(obj); {code} obj cannot be null at that point, so the check can be removed. [This will also prevent a false positive in Eclipse which later says tha obj may be null] |
10 years, 48 weeks, 6 days ago | 18682 | No Perforce job exists for this issue. | 0 | 164418 | 0|i0si5j: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-318 | CollectionUtils.size(Object object) has impossible null check |
Bug | Closed | Minor | Fixed | Unassigned | Sebb | Sebb | 16/Feb/09 19:28 | 09/Nov/14 14:31 | 28/Feb/13 19:58 | 4.0-alpha1, 4.0 | Collection | 0 | 0 | CollectionUtils.size(Object object) has impossible null check: {code} public static int size(Object object) { if (object == null) { return 0; } ... } else if (object == null) { throw new IllegalArgumentException("Unsupported object type: null"); ... {code} The Javadoc specifically says that null is allowed, so I think the object == null clause needs to be removed - it can never be true, and is just confusing. |
10 years, 48 weeks, 6 days ago | 18683 | No Perforce job exists for this issue. | 0 | 164419 | 0|i0si5r: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-317 | AbstractHashedMap(Map map) constructor calls overridable non-final method |
Bug | Closed | Minor | Fixed | Unassigned | Sebb | Sebb | 16/Feb/09 16:18 | 09/Nov/14 14:31 | 28/Feb/13 20:04 | 4.0-alpha1, 4.0 | Map | 0 | 0 | The constructor AbstractHashedMap(Map map) calls the public non-final method putAll() from the same class. This is likely to cause problems if the method is ever overridden, as the parent may not have been completely initialised when the sub-class method is invoked. Possible solution: extract the code into a common private method. Or make the method final. |
10 years, 44 weeks, 6 days ago | 18684 | No Perforce job exists for this issue. | 0 | 164420 | 0|i0si5z: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-288 | Javadoc: incorrect behavior explained for ListUtils.transformedList |
Bug | Closed | Major | Fixed | Unassigned | Paul Benedict | Paul Benedict | 17/Mar/08 16:34 | 09/Nov/14 14:31 | 28/Feb/13 19:38 | 4.0-alpha1, 4.0 | List | 0 | 0 | COLLECTIONS-256, COLLECTIONS-348 | The contract stated for ListUtils.transformedList is wrong. The list is not transformed -- it decorates the existing list and transforms NEW objects -- EXISTING objects are not transformed. Compare this to the javadoc found in MapUtils.transformedMap: "This method returns a new map (decorating the specified map) that will transform any new entries added to it. Existing entries in the specified map will not be transformed. " That little missing piece of information messed me up. Just replace "map" with "list" and append it to the existing LilstUtils javadoc. |
12 years, 2 weeks ago | 18712 | No Perforce job exists for this issue. | 0 | 164442 | 0|i0siav: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-45 | [collections] ReferenceMap size of bug. |
Bug | Closed | Critical | Cannot Reproduce | Unassigned | emily | emily | 16/Feb/06 04:26 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 0 | 0 | Operating System: other Platform: PC |
I have the following declaration of my map: Here is the code: System.err.println("elements are " + elements + "\n\t element size is " + elements.size() + "\n\tkey set " + elements.keySet() + "\n\telements:" + elements.values()); Iterator iter = elements.keySet().iterator(); while (iter.hasNext()) { Object element = iter.next(); System.err.println("next element:" + element); } System.err.println("--------------"); Here is the results below, where usually the answer is 2 but occationally 3 elements are {Concept=ConceptImpl Concept, ValueSet=ConceptImpl ValueSet} element size is 3 key set [Concept, ValueSet] elements:[ConceptImpl Concept, ConceptImpl ValueSet] next element:Concept next element:ValueSet -------------- size:3 |
14 years, 4 weeks, 4 days ago | 18953 | No Perforce job exists for this issue. | 0 | 38661 | 164663 | 0|i0sjnz: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-13 | [collections] Typo in user documentation |
Bug | Closed | Trivial | Fixed | Unassigned | Chad McHenry | Chad McHenry | 17/Jan/05 07:34 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 0 | 0 | Operating System: All Platform: All |
Will attach patch momentarily. | 15 years, 8 weeks, 4 days ago | 18985 | No Perforce job exists for this issue. | 1 | 33125 | 164695 | 0|i0sjv3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-7 | [collections] BlockingBuffer waits/notifies wrong Object? |
Bug | Closed | Major | Fixed | Unassigned | Sebb | Sebb | 12/Oct/05 04:22 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 0 | 0 | Operating System: other Platform: Other |
The code contains various examples of the form: synchronized (lock) { ... notifyAll(); } which should probably be: synchronized (lock) { ... lock.notifyAll(); } Patch to follow |
14 years, 24 weeks, 3 days ago | 18991 | No Perforce job exists for this issue. | 1 | 37028 | 164701 | 0|i0sjwf: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-121 | [Collections] Improvements to maven build |
Bug | Closed | Major | Fixed | Unassigned | Carlos Sanchez Gonzalez | Carlos Sanchez Gonzalez | 11/Oct/05 08:07 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 0 | 0 | Operating System: other Platform: Other |
Improvements to project.xml updating deprecated tags and making it easier for maven 2 users. |
14 years, 25 weeks ago | 18877 | No Perforce job exists for this issue. | 1 | 37012 | 164587 | 0|i0sj73: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-43 | [collections] serialVersionUID should be private |
Bug | Closed | Minor | Fixed | Unassigned | Sebb | Sebb | 17/Oct/05 04:03 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 0 | 0 | Operating System: other Platform: Other |
The following classes define serialVersionUID with default (package) access: HashBag TreeBag functors.* NodeCachingLinkedList LRUMap This field should be defined as private. |
14 years, 18 weeks, 6 days ago | 18955 | No Perforce job exists for this issue. | 0 | 37106 | 164665 | 0|i0sjof: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-127 | [collections] Strong reference not really cleared in TestReference*Map testcases |
Bug | Closed | Major | Fixed | Unassigned | Guilhem Lavaux | Guilhem Lavaux | 01/May/05 02:21 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 0 | 0 | Operating System: All Platform: All |
It seems TestReference*Map fail to remove completely the strong references in testPurgeValues because some optimization may be done for local variables by a JIT compiler. It may be seen with CVS head of the kaffe VM. I suggest to modify the testcases using the attached patch. It makes sure that no optimized local variables are still on the stack. The bug is present in the head of SVN tree (2005-04-30). It is fully reproduceable on kaffe VM (2005-04-30) with JIT3/x86. |
14 years, 47 weeks, 3 days ago | 18871 | No Perforce job exists for this issue. | 1 | 34689 | 164581 | 0|i0sj5r: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-129 | [collections] Flat3Map.equals() bug |
Bug | Closed | Major | Fixed | Unassigned | Stanislaw Osinski | Stanislaw Osinski | 15/May/05 01:27 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 0 | 0 | Operating System: Windows XP Platform: PC |
Flat3Map.equals() fails a simple test: public void testEquals() { Flat3Map map = new Flat3Map(); map.put("a", "testA"); map.put("b", "testB"); Flat3Map mapClone = new Flat3Map(); mapClone.put("a", "testB"); mapClone.put("b", "testA"); assertFalse("Maps should not be equal", map.equals(mapClone)); } The code of Flat3Map.equals() is: public boolean equals(Object obj) { if (obj == this) { return true; } if (delegateMap != null) { return delegateMap.equals(obj); } if (obj instanceof Map == false) { return false; } Map other = (Map) obj; if (size != other.size()) { return false; } if (size > 0) { Object otherValue = null; switch (size) { // drop through case 3: if (other.containsKey(key3) == false) { otherValue = other.get(key3); if (value3 == null ? otherValue != null : !value3.equals(otherValue)) { return false; } } case 2: if (other.containsKey(key2) == false) { otherValue = other.get(key2); if (value2 == null ? otherValue != null : !value2.equals(otherValue)) { return false; } } case 1: if (other.containsKey(key1) == false) { otherValue = other.get(key1); if (value1 == null ? otherValue != null : !value1.equals(otherValue)) { return false; } } } } return true; } while it should probably be: public boolean equals(Object obj) { if (obj == this) { return true; } if (delegateMap != null) { return delegateMap.equals(obj); } if (obj instanceof Map == false) { return false; } Map other = (Map) obj; if (size != other.size()) { return false; } if (size > 0) { Object otherValue = null; switch (size) { // drop through case 3: if (other.containsKey(key3)) { otherValue = other.get(key3); if (value3 == null ? otherValue != null : !value3.equals(otherValue)) { return false; } } case 2: if (other.containsKey(key2)) { otherValue = other.get(key2); if (value2 == null ? otherValue != null : !value2.equals(otherValue)) { return false; } } case 1: if (other.containsKey(key1)) { otherValue = other.get(key1); if (value1 == null ? otherValue != null : !value1.equals(otherValue)) { return false; } } } } return true; } -- Stanislaw Osinski http://www.carrot-search.com |
14 years, 46 weeks, 2 days ago | 18869 | No Perforce job exists for this issue. | 0 | 34917 | 164579 | 0|i0sj5b: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-15 | [collection] ListOrderedSet doesn't implements SortedSet |
Bug | Closed | Major | Won't Fix | Unassigned | Marc Guillemot | Marc Guillemot | 03/Jun/04 17:43 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 0 | 0 | Operating System: other Platform: Other |
Is it a good reason why ListOrderedSet implements Set but not SortedSet? | 15 years, 43 weeks, 3 days ago | 18983 | No Perforce job exists for this issue. | 0 | 29356 | 164693 | 0|i0sjun: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-5 | [collections] Map.debug/verbosePrint Thread Safety |
Bug | Closed | Major | Fixed | Unassigned | Arun Thomas | Arun Thomas | 11/Sep/03 10:26 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 0 | 0 | Operating System: other Platform: Other |
This bug records a discussion on the mailing list, and provides a forum for continuing that discussion. I include below the content of the mailing on the list because they raise some interesting points. ----------------------------------------------------- From: "Arun Thomas" <Arun.Thomas@solidusnetworks.com> ----------------------------------------------------- I recently noticed that the current implementation of the debugPrint and verbosePrint methods in MapUtils is not thread safe - in fact, these are the only items that are not thread safe because the indentation state for the output is preserved in a static variable. I think it would be fairly simple to make this thread safe, but it would require a change to the signature of a protected member function printIndent (PrintStream out) -> printIndent(PrintStream out, int indentDepth). I'm not really clear as to why this method is protected rather than private (can anyone clarify?). Does it need to be protected? Looking forward to input from others. -AMT ------------------------------------------------------ From: Stephen Colebourne [scolebourne@btopenworld.com] ------------------------------------------------------ The methods that call this one are synchronized to protect them, so it should be thread-safe. However, I would prefer them not to need to be synchronized. If you want to submit a patch that reworks the methods that would be great. Incompatable change? The protected method should remain and be deprecated, as it may be used by a MapUtils subclass (feasible but unlikely). However, I would prefer just to go incompatable change on this one. Other committers may differ, but if they don't I'll just commit the incompatable change. Stephen --------------------------------------- From: Janek Bogucki [yan@studylink.com] --------------------------------------- These methods are synchronized so are currently thread safe. public static synchronized void verbosePrint (...) public static synchronized void debugPrint (...) I would guess that a second intentional benefit of the synchronization is to prevent overlapping invocations writing to System.out at the same time. -Janek ------------------------------------------------------ From: Stephen Colebourne [scolebourne@btopenworld.com] ------------------------------------------------------ I like the System.out theory. Its probably unintentional, but it true. So only a documentation patch is required then...:-) Stephen |
16 years, 28 weeks, 3 days ago | 18993 | No Perforce job exists for this issue. | 1 | 23092 | 164703 | 0|i0sjwv: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-66 | FastArrayList, FastHashMap and FastTreeMap not thread safe |
Bug | Closed | Major | Fixed | Unassigned | Paul Jack | Paul Jack | 10/Apr/02 22:03 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 0 | 0 | Operating System: All Platform: All |
Hi, I noticed that version 2.0 of the Commons Collections has been released so I thought I'd browse through the code. While doing so I noticed something about FastArrayList, FastHashMap and FastTreeMap. List and Map objects can return views on their contents that can be modified. For instance, elements can be removed from an ArrayList via its iterator(). Elements can be removed from a map via its keySet() or its values() collection. A TreeMap can also return a submap that can be modified. Generally, changes on a view of a collection are reflected in the original and vice-versa. The problem is, with FastArrayList or FastHashMap, in "fast" mode, if somebody tries to modify a collection view (say, a keySet() of a FastHashMap) they will never enter the FastHashMap's monitor. The state of the FastHashMap can become corrupted if more than one thread attempts to modify its keySet(); and threads attempting a fast get(Object) on a FastHashMap while another thread modifies its keySet() may get faulty data back. Here's the list of methods that worry me: FastArrayList.iterator() FastArrayList.subList(int, int) FastHashMap.keySet() FastHashMap.entrySet() FastHashMap.values() FastTreeMap.keySet() FastTreeMap.entrySet() FastTreeMap.values() FastTreeMap.subMap(Object, Object) FastTreeMap.headMap(Object) FastTreeMap.tailMap(Object) |
17 years, 34 weeks ago | 18932 | No Perforce job exists for this issue. | 0 | 7924 | 164642 | 0|i0sjjb: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-74 | [collections] Predicated Collections Throw IllegalStateException |
Bug | Closed | Major | Fixed | Unassigned | Nick Heudecker | Nick Heudecker | 01/Apr/04 12:50 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 0 | 0 | Operating System: other Platform: Other |
When calling ListUtils.predicatedList(List,Predicate), the underlying class used to create the predicated collection throws an IllegalArgumentException when it encounters an item that failed evaluation. This is not the documented behavior for ListUtils, and it makes that method unusable. It probably effects the other predicated collections available in the other Utils classes. |
16 years, 4 days ago | 18924 | No Perforce job exists for this issue. | 0 | 28115 | 164634 | 0|i0sjhj: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-106 | [collections] test failures for subclasses of AbstractBidiMapDecorator and friends |
Bug | Closed | Major | Fixed | Unassigned | Michael Heuer | Michael Heuer | 30/Dec/03 05:59 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 0 | 0 | Operating System: All Platform: All |
The attached test case fails for a class that extends AbstractOrderedBidiMapDecorator: Testcase: testFirstKey took 0.04 sec FAILED expected:<foo> but was:<again> junit.framework.AssertionFailedError: expected:<foo> but was:<again> at org.apache.commons.collections.bidimap.AbstractTestOrderedBidiMap.testFirstKey(AbstractTestOrderedBidiMap.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Testcase: testFirstKeyTestcase: testLastKey took 0 sec FAILED expected:<all> but was:<you> junit.framework.AssertionFailedError: expected:<all> but was:<you> at org.apache.commons.collections.bidimap.AbstractTestOrderedBidiMap.testLastKey(AbstractTestOrderedBidiMap.java:119) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Testcase: testLastKeyTestcase: testNextKey took 0.05 sec FAILED expected:<we'll> but was:<gee> junit.framework.AssertionFailedError: expected:<we'll> but was:<gee> at org.apache.commons.collections.bidimap.AbstractTestOrderedBidiMap.testNextKey(AbstractTestOrderedBidiMap.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Testcase: testNextKeyTestcase: testPreviousKey took 0 sec FAILED expected:<gosh> but was:<again> junit.framework.AssertionFailedError: expected:<gosh> but was:<again> at org.apache.commons.collections.bidimap.AbstractTestOrderedBidiMap.testPreviousKey(AbstractTestOrderedBidiMap.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Testcase: testPreviousKeyTestcase: testBidiPut took 0 sec Testcase: testBidiGetKey took 0 sec Testcase: testBidiGetKeyInverse took 0 sec Testcase: testBidiInverse took 0 sec FAILED Inverse of inverse is not equal to original. expected same:<{key1=value1, key2=value2, key3=value3}> was not:<{key1=value1, key2=value2, key3=value3}> junit.framework.AssertionFailedError: Inverse of inverse is not equal to original. expected same:<{key1=value1, key2=value2, key3=value3}> was not:<{key1=value1, key2=value2, key3=value3}> at org.apache.commons.collections.bidimap.AbstractTestBidiMap.testBidiInverse(AbstractTestBidiMap.java:232) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) The testBidiInverse test also fails for classes that extend AbstractBidiMapDecorator and AbstractSortedBidiMapDecorator (not attached). |
16 years, 13 weeks, 6 days ago | 18892 | No Perforce job exists for this issue. | 1 | 25811 | 164602 | 0|i0sjaf: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-92 | MultiHashMap.values() isn't backed by Map |
Bug | Closed | Major | Fixed | Unassigned | Paul Jack | Paul Jack | 03/Jun/02 15:30 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 0 | 0 | Operating System: All Platform: All |
The values() collection of MultiHashMap isn't backed by the map; changes to the map are not reflected in a values() collection, and changes to the values() collection are not reflected in the map. Though MultiHashMap deliberately violates the Map contract in other ways, there seems to be no legimate reason for it to violate the values() contract; since values() can be implemented according to contract, it probably should be. |
17 years, 19 weeks, 1 day ago | 18906 | No Perforce job exists for this issue. | 0 | 9573 | 164616 | 0|i0sjdj: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-102 | Bag interface violates Collection contract |
Bug | Closed | Minor | Fixed | Unassigned | Paul Jack | Paul Jack | 29/May/02 02:49 | 15/Mar/08 21:36 | 14/Jul/06 12:05 | 1 | 0 | Operating System: All Platform: All |
The following methods as defined by the Bag interface violate their corresponding definitions in the Collection interface: add(Object), addAll(Collection) The Collection interface specifies that the add method should return true if the collection changes as a result of the call. Since a bag's size always increases as a result of an add operation, Bag.add should always return true. The bag interface specifies that add(Object) will only return true if the object was not already in the unique set. remove(Object) The Collection interface states that only one occurrence of a given object should be removed as a result of this method. The Bag interface specifies that all occurrences will be removed. removeAll(Collection) retainAll(Collection) containsAll(Collection) The Collection specification does not respect cardinality for these methods; the Bag interface does. The add, addAll and remove methods can be fixed easily, and code relying on the old behavior can be rewritten simply using existing Bag methods: boolean r = bag.add(obj) can be replaced with: boolean r = !bag.contains(obj); bag.add(obj) And boolean r = bag.remove(obj) can be replaced with boolean r = bag.remove(obj, bag.getCount(obj)); The existing bulk operations could be implemented with static utility methods in CollectionUtils (or possibly BagUtils), which would allow a smooth migration path for code that relies on the current bulk operation behavior. |
13 years, 37 weeks, 4 days ago | 18896 | No Perforce job exists for this issue. | 1 | 9467 | 164606 | 0|i0sjbb: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-131 | performing get(Object) operations inside of an iteration produces an infinite loop |
Bug | Closed | Major | Fixed | Unassigned | Morgan Delagrange | Morgan Delagrange | 09/May/02 01:03 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 0 | 0 | Operating System: other Platform: Other |
I just "fixed" LRUMap, which was not promoting get(Object) operations correctly. However, now if you perform a get(Object) within an iteration of the keySet(), it will keep promoting values to the top and producing an infinite loop. This needs to be fixed, by making the collection throw a ConcurrentModificationException, or by fixing the behaviour in some other way. |
17 years, 43 weeks, 1 day ago | 18867 | No Perforce job exists for this issue. | 0 | 8913 | 164577 | 0|i0sj4v: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-76 | FastArrayList, FastHashMap and FastTreeMap not cross-platform |
Bug | Closed | Major | Won't Fix | Unassigned | Paul Jack | Paul Jack | 17/May/02 23:51 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 0 | 0 | Operating System: other Platform: Other |
An optimizing compiler or a processor pipeline can reorder the operations that clone the internal collection and reassign the reference to the clone. A thread invoking a read operation can conceivably fetch a reference to a non- fully-cloned collection, resulting in arbitrary behavior. There seems to be no way to actually fix this bug, given the current Java Memory Model. The code does seem to work on architectures that supply their own more strict memory models, such as single-processor 386 systems. At minimum, the documentation for these classes should be updated to indicate that they are not cross-platform. The Java Memory Model is currently under revision, and some future version of Java will allow these classes to work by making the internal collection reference volatile. (In the future, the volatile keyword will have better semantics; a write to any volatile field by a thread will force a write of ALL modifications made by that thread). References: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html (These all deal with the double-checked locking algorithm, but the concepts apply to these classes as well. Do a google search for "Bill Pugh" for more in- depth information). |
17 years, 34 weeks, 3 days ago | 18922 | No Perforce job exists for this issue. | 0 | 9206 | 164632 | 0|i0sjh3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-133 | JavaDoc for ListUtils and FactoryUtils missing |
Bug | Closed | Major | Incomplete | Unassigned | Colin | Colin | 04/Oct/02 20:16 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 0 | 0 | Operating System: other Platform: Other |
ListUtils and FactoryUtils are missing from the currently accessable commons collection javadoc. Maybe there are other classes missing? |
17 years, 19 weeks, 1 day ago | 18865 | No Perforce job exists for this issue. | 0 | 13288 | 164575 | 0|i0sj4f: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-83 | Implementation of List with an AVLTree (TreeList) |
Bug | Closed | Major | Duplicate | Unassigned | Joerg Schmuecker | Joerg Schmuecker | 05/Feb/04 18:33 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 0 | 0 | Operating System: All Platform: All |
The existing Java List implementations are rather slow if it comes to big lists and insertions and/or random access. To mitigate that this List is based on an AVL-Tree and uses offsets to locate objects. The following benchmarks show the performance compared to LinkedList and ArrayList. add insert get TreeList 300 501 110 ArrayList 70 20390 20 LinkedList 50 226636 279742 add - 100K times add( new Object() ) insert - 100k times add( random() * 100K, new Object() ) on a List with 100K elements. get - 100k times get( random() * 100k ) on a List with 200K elements. P.S.: I will try to attach the code as a zip. |
16 years, 8 weeks, 5 days ago | 18915 | No Perforce job exists for this issue. | 0 | 26679 | 164625 | 0|i0sjfj: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-94 | [collections] New feature: Extend ReferenceMap with IdentityMap functionality (WeakIdentityHashMap) |
Bug | Closed | Major | Fixed | Unassigned | Andy Malakov | Andy Malakov | 29/Jan/04 06:22 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 0 | 0 | Operating System: All Platform: All |
Hello All, I would like to ask your opinion on providing IdentityMap features to ReferenceMap. (I am particularly interested in WeakIdentityHashMap) Object cache is often implemented using ReferenceMap (WeakHashMap). This class delegates decision on when to de-cache an objects on Java GC. In many systems Java objects that represent database instances use database identity: methods Object.equals(Object) and Object.hashCode() are redefined to use database identity (identity defined in terms of object table + object primary keys). When traditional java.util.Map is used to implement database caches different instances of the same database objects present a problem: instances override each other. Class java.util.IdentityHashMap (Apache Collections 3.0: IdentityMap) can be used to solve this problem - this approach uses System.identityHashCode() to obtain reference hashCode and Java comparison operator to compare keys (and values). What I need is functionality of IdentityMap combined with WeakReference-based keys. Is it possible to extend ReferenceMap with an ability to use reference identity instead of object identity? I can send you my prototype if you are interested (it adds about ten lines of code to ReferenceMap). Here are some links to Sun's bug parade pages that describe similar feature request for Java's java.util.WeakHashMap: http://developer.java.sun.com/developer/bugParade/bugs/4809420.html http://developer.java.sun.com/developer/bugParade/bugs/4500542.html P.S. There is a need for this feature in Apache DB-OJB project. All the Best, Andy |
15 years, 48 weeks, 6 days ago | 18904 | No Perforce job exists for this issue. | 2 | 26503 | 164614 | 0|i0sjd3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-109 | Bug in CollectionUtils |
Bug | Closed | Major | Fixed | Unassigned | Maarten Coene | Maarten Coene | 24/Jun/02 15:12 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 0 | 0 | Operating System: All Platform: All |
Hi, there is a bug in CollectionUtils. If you pass in a Collection object which is not an instance of List to the CollectionUtils.index() methods, the method doesn't work: it just returns the given Collection instead of the i-th value in the Collection. I've already reported this (including a patch) to the commons-dev mailinglist, but there was no reaction, that's why I'm trying it this way. Here is the patch (if possible, I will also add an attachment including this patch) regards, Maarten cvs diff -u CollectionUtils.java Index: CollectionUtils.java =================================================================== RCS file: /home/cvspublic/jakarta- commons/collections/src/java/org/apache/commons/collections/CollectionUtils.java ,v retrieving revision 1.8 diff -u -r1.8 CollectionUtils.java --- CollectionUtils.java 12 Jun 2002 03:59:15 -0000 1.8 +++ CollectionUtils.java 18 Jun 2002 12:23:34 -0000 @@ -500,6 +500,17 @@ } } } + else if(obj instanceof Collection) { + Iterator iterator = ((Collection)obj).iterator(); + while(iterator.hasNext()) { + idx--; + if(idx == -1) { + return iterator.next(); + } else { + iterator.next(); + } + } + } return obj; } |
17 years, 34 weeks, 3 days ago | 18889 | No Perforce job exists for this issue. | 1 | 10168 | 164599 | 0|i0sj9r: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-10 | [collections] minor javadoc fixes for OrderedIterator |
Bug | Closed | Minor | Fixed | Unassigned | Michael Heuer | Michael Heuer | 20/Jul/04 03:40 | 15/Mar/08 21:35 | 15/Mar/08 21:35 | 0 | 0 | Operating System: other Platform: Other |
Minor javadoc fixes for org.apache.commons.collections.OrderedIterator. diff -u attached. |
15 years, 27 weeks, 5 days ago | 18988 | No Perforce job exists for this issue. | 1 | 30191 | 164698 | 0|i0sjvr: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-108 | [collections] [RFE] RemoveElementTransformer |
Bug | Closed | Major | Won't Fix | Unassigned | Guillaume Coté | Guillaume Coté | 05/Aug/04 01:23 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 0 | 0 | Operating System: All Platform: All |
There is transformer remove a element from a Set (modifing the original ser). If I write proper javadoc and test case, could it be included in commons collections. |
15 years, 24 weeks, 2 days ago | 18890 | No Perforce job exists for this issue. | 2 | 30477 | 164600 | 0|i0sj9z: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-63 | [collections] compile failes with jdk 1.5 due to "enum" |
Bug | Closed | Blocker | Cannot Reproduce | Unassigned | Georg Müller | Georg Müller | 06/Aug/04 05:21 | 02/May/13 02:28 | 15/Mar/08 21:35 | 0 | 0 | LANG-124 | Operating System: other Platform: Other |
enum is a keyword in jdk 1.5 so a lot off commons (not only collections) did not compile. A lot of variables have the name enum. Could this be changed, please. |
15 years, 27 weeks, 5 days ago | 18935 | No Perforce job exists for this issue. | 0 | 30503 | 164645 | 0|i0sjjz: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Commons Collections | COLLECTIONS-79 | [collections] [RFE] MapToArrayTransformer |
Bug | Closed | Major | Won't Fix | Unassigned | Guillaume Coté | Guillaume Coté | 05/Aug/04 01:11 | 15/Mar/08 21:36 | 15/Mar/08 21:36 | 0 | 0 | Operating System: other Platform: Other |
There is transformer received map and return a array containing the values of a list of keys. If I write proper javadoc and test case, could it be included in commons collections. |
15 years, 24 weeks, 2 days ago | 18919 | No Perforce job exists for this issue. | 1 | 30474 | 164629 | 0|i0sjgf: |
| Generated at Wed Mar 18 03:02:30 UTC 2020 by Subhannita Sarcar using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b. |